软件开发与使用

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

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

出错的是以下几行：

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 本体里不行。

你能编译吗？

试着把 init.cpp 第 78 行从：

#ifdef __WXGTK__

改成：

#ifndef __WXMSW__

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

试试 -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 之前，很多人都被它折磨过。

这篇教程写得真不错。希望有人能确认，按这篇教程操作是否顺利、有没有遇到问题。

其他参与者原话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 会成为更主流的版本。

这已进 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

其他参与者原话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。谢谢。

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

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

有道理，我相信没有 SSE2 时你可以关闭挖矿功能后运行客户端。

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

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

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

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

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

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

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

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

是的，0.3.7 已包含这个补丁，它是在 rev 112 中加入的。

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

其他参与者原话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 链接。

其他参与者原话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

其他参与者原话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。我以为自己已经很小心，没有接受任何更新。

""./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。我以后再也不升级了。不知道什么时候才有时间重装系统降级，但至少只要不再升级，问题会随着时间自行缓解。

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

这样好使了吗？

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

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

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

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

顺便说一下，你的主机能使用我构建的 bitcoind 吗，还是必须自己构建？

我必须自己构建。它有论坛上已经报告过的同样问题：/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found。

真希望能弄清楚怎么修复它。你的系统装的是哪个版本的 GLIBCXX？

一定要尽快升级到 Bitcoin 0.3.3。

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

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

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

告诉我行不行。

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

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

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

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

makefile.unix 已回退。

回得有点晚，但万一别人也遇到同样的问题。编译输出有 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 上的构建说明。

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

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

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

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

我把它放在 bitcoin.org/download/linux64-0.2.7.1.tar.gz。你拿到后可以删掉。

我考虑了什么可能导致你遇到的问题，并作了一处修改，包含在这个构建中。这段代码可能不安全，尽管大概总能侥幸运行。

util.cpp 中的旧代码：

const char* wxGetTranslation(const char* pszEnglish)
{
     // Wrapper of wxGetTranslation returning the same const char* type
     // as was passed in
     static CCriticalSection cs;
     CRITICAL_BLOCK(cs)
     {
         // Look in cache
         static map<string, char*> mapCache;
         map<string, char*>::iterator mi = mapCache.find(pszEnglish);
         if (mi != mapCache.end())
             return (*mi).second;

         // wxWidgets translation
         const char* pszTranslated =
             wxGetTranslation(wxString(pszEnglish, wxConvUTF8)).utf8_str();

         // We don't cache unknown strings because caller might be
         // passing in a dynamic string and we would keep allocating
         // memory for each variation.
         if (strcmp(pszEnglish, pszTranslated) == 0)
             return pszEnglish;

         // Add to cache, memory doesn't need to be freed.  We only
         // cache because we must pass back a pointer to permanently
         // allocated memory.
         char* pszCached = new char[strlen(pszTranslated)+1];
         strcpy(pszCached, pszTranslated);
         mapCache[pszEnglish] = pszCached;
         return pszCached;
     }
     return NULL;
}

新代码：

const char* wxGetTranslation(const char* pszEnglish)
{
     // Wrapper of wxGetTranslation returning the same const char* type
     // as was passed in
     static CCriticalSection cs;
     CRITICAL_BLOCK(cs)
     {
         // Look in cache
         static map<string, char*> mapCache;
         map<string, char*>::iterator mi = mapCache.find(pszEnglish);
         if (mi != mapCache.end())
             return (*mi).second;

         // wxWidgets translation
         wxString strTranslated = wxGetTranslation(wxString(pszEnglish,
             wxConvUTF8));

         // We don't cache unknown strings because caller might be
         // passing in a dynamic string and we would keep allocating
         // memory for each variation.
         if (strcmp(pszEnglish, strTranslated.utf8_str()) == 0)
             return pszEnglish;

         // Add to cache, memory doesn't need to be freed.  We only
         // cache because we must pass back a pointer to permanently
         // allocated memory.
         char* pszCached = new char[strlen(strTranslated.utf8_str())+1];
         strcpy(pszCached, strTranslated.utf8_str());
         mapCache[pszEnglish] = pszCached;
         return pszCached;
     }
     return NULL;
}

如果你仍然怀疑这段代码，测试时可以把它改为：

const char* wxGetTranslation(const char* pszEnglish)
{
     return pszEnglish;
}

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己构建的 bitcoind，但还没怎么成功。它总是占用系统的全部内存，最后崩溃。能请你再发我一次最新的 64 位 bitcoind 构建吗？这样我就能看看，问题是否出在我自己的构建。

其他参与者原话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 包的。

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

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

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

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

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。

好，我做了一个构建目标 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 大概能正常工作，但还是希望你能把那个问题调试出来。

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

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

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

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

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

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

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

引用中本聪此前的文字中本聪来源 ↗

引用 Martti Malmi 的文字Martti Malmi来源 ↗

关于让同一个二进制程序在没有 GUI 时运行，我找到几条线索：

1. GTK 支持程序在没有显示环境时运行： http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check。不过，这没说明 wxWidgets 能否做到。

我看到它在 wxApp::Initialize 中调用 gtk-init-check。

我可以在子类中重写 Initialize，调用原来的方法，同时抑制错误消息，忽略返回值。看起来能用。

这样能用。再处理几件事，我就上传。

我们需要告诉大家安装 GTK 库。你记得安装 GTK 的 apt-get 命令吗？没有安装 GUI 的情况下，可以安装它吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

我还没用其他东西测试过自己的 JSON-RPC 服务器。如果你测试了，请告诉我情况如何。你用的是 Python，对吗？

让 Linux 版本在未安装 GTK 的情况下运行，将是另一项任务。

是的，用 Python。我还没测试 JSON-RPC，因为还没有在 vps 上运行比特币。即使安装了 GTK 库，没有窗口管理器它也无法运行。我在 wxWidgets 论坛上问了（http://wxforum.shadonet.com/viewtopic.php?t=26954），但他们也没什么 头绪。也许我们就是需要做两个不同的二进制文件。

我大概会让步，照这个办法做。我可以把初始化和关闭移到 init.cpp、start.cpp 或类似文件中，只链接 wxbase，不链接 ui.o 和 uibase.o。

wxWidgets 社区主要是 Windows 用户，他们对 GTK 不会知道太多。

你不是有一台 Ubuntu 笔记本，可以用来测试和编译，就不用折腾 vps 了吗？

我在 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 包。

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

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

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

发行版里的 bitcoin 二进制静态链接了 wxWidgets 库，它动态链接的库（openssl 和 GTK）则由 Ubuntu 自带，所以无需借助 .deb 安装依赖也能运行。

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

你只是想运行程序，还是真的需要编译？有一个 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 里跑得挺好。

明白，我会改成这样，免得再被弄坏：

     if (str.Find('\xC2') != wxNOT_FOUND)
         str.Remove(str.Find('\xC2'), 1);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我没有有意改它，一定是某种编码问题。

引用中本聪此前的文字中本聪来源 ↗

为什么作这个改动？

#if !wxUSE_UNICODE ... if (str.Find('Â') != wxNOT_FOUND) str.Remove(str.Find('Â'), 1); 改为： if (str.Find('�') != wxNOT_FOUND) str.Remove(str.Find('�'), 1);

wxFormBuilder 会自动把 (c) 符号转成 UTF-8。在 wxWidgets-2.8.9 ansi 中，它会显示为版权符号，外加一个多余的乱码字符，这个变通处理就是用来修复非 unicode（ansi）情况下的问题。

为什么作这个改动？

#if !wxUSE_UNICODE
...
     if (str.Find('Â') != wxNOT_FOUND)
         str.Remove(str.Find('Â'), 1);

改为：

     if (str.Find('�') != wxNOT_FOUND)
         str.Remove(str.Find('�'), 1);

wxFormBuilder 会自动把 (c) 符号转成 UTF-8。在 wxWidgets-2.8.9 ansi 中，它会显示为版权符号，外加一个多余的乱码字符，这个变通处理就是用来修复非 unicode（ansi）情况下的问题。

我肯定是不小心把 z 打成了 j。它是 bz2 格式。改名为 .tar.bz2，或者直接执行 tar -jxvf。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

压缩包打不开，提示“not in gzip format”。

我提交了 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。所以你还是得自己下载构建。

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

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

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

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

#ifdef __BSD__

#include

#endif

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

其他参与者原话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 过文件，听起来里面应该有内容。程序对这个文件有写权限吗？

其他参与者原话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 下的任一 Mac GUI 移植版本，用 __WXOSX__。

* 如果要判断是否为 Mac OS X 下的任一移植版本（比如 wxGTK 以及 wxBase），用 __DARWIN__"

其他参与者原话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 控件的工作方式，决定了要保持它更新，就得频繁通信。

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

对，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（续）原帖 ↗

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

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

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

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

那我最好也安装 64 位版本。我猜是 64 位 Linux 上的 32 位 Berkeley DB 有什么问题。

顺便问一下，在功能列表的致谢等地方，你希望我称你为 sirius-m 还是 Martti Malmi？我想大多数项目为了保持一致，都使用真名。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

程序终止了几次，debug.log 里都是来自 Db::close 的同一个错误。Db.log 中有：

close: Bad file descriptor blkindex.dat: Bad file descriptor

我运行的是 64 位 Ubuntu 发行版。

引用中本聪此前的文字中本聪来源 ↗

现在唯一的问题是他遇到的 DB 异常。

---

EXCEPTION: 11DbException Db::open: Bad file descriptor bitcoin in ThreadMessageHandler()

---

EXCEPTION: 11DbException Db::close: Bad file descriptor bitcoin in ThreadMessageHandler()

我原本以为那些是 Wine 的问题，但他在 Linux 上照样遇到了。他试过把 datadir 移到另一个驱动器，没有用。我从没遇到过。我正在运行一项压力测试，连续产生大量活动和数据库访问，也从没出现过。

他用 Ubuntu 64 位，我用 32 位，所以我假设区别就在这里。你的 Linux 机器是 64 位还是 32 位？你有没有遇到过 DB 异常？（也看看 db.log。）既然 test5 已经修复了僵尸问题，你能开始在自己的 Linux 机器上运行它吗？我们可以用第三个样本，更清楚地了解现在面对的情况。 DB 异常没有被捕获，所以遇到时会使程序停止。

顺便说一句，zetaboards 坚持显示“会员编号”，所以你最好尽快注册，抢一个好账号数字。

你真的不该继续在 Wine 中运行了，你正在遇到数据库错误（db.log）。你大概是为了应付数据库损坏，才养成了转移到全新安装的这套操作习惯。如果真有什么办法会丢失未确认区块，那只能是数据库错误。你在 Linux 构建中发现的任何问题都可以修复。Berkeley DB 深处的 Wine 兼容性问题则无法修复。

我想，Linux 构建所用的 GCC 4.3.3 对 SHA-256 代码的优化，比 Windows 上旧的 GCC 3.4.5 更好。当初寻找最佳 SHA-256 代码时，有很多经过手工调整、高度优化的 SHA1 代码可用，但 SHA-256 还不多。我应该看看能否把 MinGW 升级到 4.3.x，让两边处于同一起跑线。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

所有参与制作这个 Linux 构建的人，做得真的很棒！谢谢大家的努力。有些比特币已经开始成熟，所以我暂时会继续运行 Linux 客户端，直到判断出它生成功能至少与运行在 Wine 中的 Windows 版一样好，还是更好。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

另一种我希望同时运行多个实例的情况，是升级 bitcoin。我会取消旧版 bitcoin 的生成币复选框，再使用单独的数据目录，启动新版 bitcoin 并开始生成币，等旧版程序的币成熟后，再把它们发到新版程序，然后关闭旧版。我更喜欢全新安装，而不是保留旧数据升级。

引用中本聪此前的文字中本聪来源 ↗

谢谢，我看出发生什么了。因为第一个节点很慢，程序最后向其他所有人都请求区块，结果只是把一切都拖慢了。我能修复，只是需要花点时间想想正确的办法。

有未确认内容时关闭程序没有风险。 当你创建交易或新区块时，程序会立即将它广播到网络。之后不断增加的 #/已确认 数字只是在监测结果。在这段时间里，你的节点不会做任何促进接受的事情。

现在它在 Linux 上能稳定运行了，只有一个例外：如果在 GUI 线程之外调用 wxMessageBox()，就会崩溃，因为 Linux 上的非 GUI 线程不能打开窗口。我还没来得及修复这一点。我一直在运行压力测试，功能正常。

在 UI 线程之外使用 wxWidgets，大部分功能都不是线程安全的，但在 Windows 上，经验上凡是与 UI 无关的东西都没问题。结果在 GTK 上，不具备线程安全的地方更多。我一次替换了很多东西，所以不知道是否只是某一处导致的（可能是 Repaint），但我必须假定，任何使用 wxString 的 wx 函数，在 UI 线程之外都不安全。真糟糕，那些好用的 wxWidgets 可移植性辅助函数都不能用了。我保留了 wxThread::GetCPUCount() 之类的简单功能，我查过源码，全是数值运算；而 wxMutex 必须安全，否则就毫无用处。

有个问题：退出后立即重新运行，无法绑定 8333 端口。大约一分钟后，端口才会释放。除非我漏了什么，否则我确实在退出前关闭了套接字，所以不知道还能做什么。也许 Linux 就是这样，要花一分钟才能释放曾绑定的端口。可能是一种安全功能，防止木马杀掉 Web 服务器后，马上顶替它，接收所有客户端的重试请求。

还得弄清楚怎样正确制作 xpm 版本的图标。

不知道数据库的 dat 文件能否与 Windows 互换。

我把 linux 改动合并到了 SVN 主干。现在它可以编译并运行。我认为所有问题都在界面上。菜单很快就会失灵，应该重绘时却不重绘，除非我调整窗口大小，而且界面还出现了一些段错误。用 gdb 调试应该不会太难。我还没有测试它能否与其他节点正常协作，所以先不要让它联网。

添加了 build-unix.txt 和 makefile.unix

告诉你一声，我还在做 Linux 构建，免得我们重复工作。我已经完成链接并运行起来，正在处理运行时问题，例如把位图加载从资源改成 xpm。

有些依赖提供 Debian 软件包，不必我们自己编译： apt-get install build-essential apt-get install libgtk2.0-dev apt-get install libssl-dev

我得看看 Berkeley DB 或 Boost 有没有软件包。

OpenSSL 我们会采用动态链接，我很确定 Linux 总是预装它。GTK 必须动态链接。我不完全确定它是否默认预装。

已经差不多了。我修了几处，让它完成了编译，但我不知道该链接哪些系统库，因此有一大堆未定义引用。

我修改了 makefile，让它在 /usr/local 和各项默认的“make install”位置下查找。我把自己的操作和使用的开关写进了 build-unix.txt。目前暂时用 wxWidgets 2.8.9，因为它与 Windows 上的版本相同，我不想在切换平台时，还要猜测是否同时存在版本变化带来的问题。不过 2.8.10 或 2.9.0 应该也没问题。我选择把 wxWidgets 编译为单个库，因为反正我们几乎要链接它的所有库。

我添加了 xpm 文件，这是 Windows 以外的系统用来代替 RC 文件的格式。它们是巧妙的 C 文件，用静态数组定义图形。bitcoin 图标有 5 个不同版本，但我没能弄清 xpm 如何处理这种情况，所以只放了最大的那个。也许 GTK 会替你缩放。我不知道这些是否正确，但它们能编译。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我已经把目前移植的内容上传到 svn/branches。Util、script、db 和头文件现在都能完整编译，net.cpp 则能部分编译，所以还有工作要做。

_beginthread 在 Linux 上没有直接对应的函数，所以我改用了 Boost 线程。

heapchk() 只是一个没在用的 MSVCRT 调试功能。在 Linux 上可以让它什么也不做。OpenSSL 在 Linux 上会自动使用 /dev/urandom 提供随机种子，所以 RandAddSeedPerfmon 也可以什么都不做。

在我们充分完成离线测试之前，别让它连接网络。如果你有两台电脑，先断开互联网，用“bitcoin -connect=<ip>”让它们互连，一台 windows，一台 linux。-connect 允许连接 192.168.x.x 这样的不可路由地址。如果它发出某种我们还没想到要检查的畸形垃圾数据，或者以其他方式干扰网络，我们可不想因此损害网络的可靠性声誉。

等你有能编译、可供测试的版本时，我有时间做些测试。我可以把它加入目前正在针对已有改动运行的压力测试。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我在 util.h 中加了一个 #ifdef，用 Linux 的 gettimeofday 替换 QueryPerformanceCounter。更新到 wxWidgets 2.9 后，一些 Unicode/ANSI 错误没有改代码就解决了。目前我在 Linux 上遇到的唯一编译错误，来自 util.h 中的 heapchk()。

引用中本聪此前的文字中本聪来源 ↗

我修复了遇到的一些不可移植的内容： QueryPerformanceCounter printf 格式字符串中的 %I64d Sleep CheckDiskSpace

如果你知道还有其他应该由我修复的不可移植内容，请告诉我。

我想把 debug.log 和 db.log 移到数据文件所在的目录（%appdata%\Bitcoin），而不再放到碰巧作为当前目录的位置。

我修复了遇到的一些不可移植的内容：
QueryPerformanceCounter
printf 格式字符串中的 %I64d
Sleep
CheckDiskSpace

如果你知道还有其他应该由我修复的不可移植内容，请告诉我。

我想把 debug.log 和 db.log 移到数据文件所在的目录（%appdata%\Bitcoin），而不再放到碰巧作为当前目录的位置。

我采取了一个简单办法：看 wxWidgets 的源代码，看看他们怎么做。他们在非 MSW 平台上直接把它映射到 wxMutex，而 wxMutex 确实有 TryEnter，所以能完全对应上。

我把积累的所有改动都提交到了 SVN，包括重写 util.h 中的 CCriticalSection，以及 util.cpp 中 OpenSSL 的互斥锁回调，以便在非 Windows 平台上全部通过 wxWidgets 实现。

如果我们让它在 Linux 上运行起来，我会先在这里离线跑一遍测试套件，然后可以把一个未发布的构建版交给 LibertyStandard 测试一段时间，再公开发布。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

我会把 CriticalSection 代码改成 wxCriticalSection，再上传到 SVN（有点棘手）。不过，我还不知道 TryEnterCriticalSection 该怎么办。我想自己差不多准备好把所有内容提交上去了。

Boost 的互斥锁在这里会有帮助吗？

http://www.boost.org/doc/libs/1_40_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts

我会把 CriticalSection 代码改成 wxCriticalSection，再上传到 SVN（有点棘手）。不过，我还不知道 TryEnterCriticalSection 该怎么办。我想自己差不多准备好把所有内容提交上去了。

你大概是对的，是时候做一个 linux 版本了。我一直在配置自己的 linux 机器，并编译依赖项。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

好。我把 Windows 线程和套接字库的包含文件替换成了对应的 POSIX 文件，现在只剩下几个错误，大多来自 CriticalSections。如果我让它运行起来，就会放进 svn/branches，现在还不必作为正式版本发布。

Sourceforge 实在太慢了。不过我也不知道还有什么办法。它已经成了惯例，随便一个项目往往都有一个 projectname.sourceforge.net 网站。在 google 搜索里看到 whatever.sourceforge.net 时，我就会认为那是官方网站。

有没有办法让 Bitweaver 允许用户编辑（或许也能删除）自己在论坛里的消息？

已经迫不及待想移植到 Linux 了吗？这不是一个能轻易作出的决定，因为一旦完成，我的测试和构建工作量就会翻倍。不过，我确实担心 Liberty 遇到的 Wine 崩溃问题。

我已经尽量保持可移植性，使用标准 C 的东西，而不是 Windows 调用。线程使用 _beginthread，它属于标准 C 库。wxWidgets 有 wxCriticalSection 之类的东西可供我们使用。套接字代码使用 send/recv，我想这与 unix 相同，因为 Microsoft 是从 BSD 移植套接字的。我们需要直接控制套接字，把它藏在抽象层后面不是好主意。寻找跨平台辅助函数时，wxWidgets 是个好地方。如果可以，我想避免代码中到处都是 #ifdef。任何使用超过一次的东西，大概都可以做成 util.cpp 中的函数，把 #ifdef 放在函数里。

顺便说一下，我目前有很多未提交的改动，因为其中包括一些关键的协议转换，在我彻底测试之前，不能把它们放到网络上。应该不用太久了。

你能让安装程序卸载 Startup 文件夹中的图标吗？我想它应该在普通程序组里安装和卸载图标，而对 Startup 文件夹中的图标，只负责卸载。我猜它是同时安装和卸载 Startup 文件夹图标，还是仅仅卸载，区别也不大。

Martti 对网站与 Linux 移植的来信Martti Malmi来源 ↗

IS_LIVE 选项确实设为 false，但它只影响用户能否看到错误消息。我注意到网站有时很慢，有时加载要长达 30 秒。我认为这与 Sourceforge 的托管有关。Bitweaver 应该是最轻量的 PHP CMS 之一，但我可以检查它有没有什么问题。

换个话题，你觉得我们能用 Boost 的线程和套接字库，代替 Windows 专用的那些吗？代码里还用了其他只能在 Windows 上使用的函数吗？

此前中本聪的询问中本聪来源 ↗

知道它出了什么事吗？我每次看的时候，它都是好的。

Eugen 引用的中本聪旧信中本聪来源 ↗

bitcoin.sourceforge.net 现在看起来正常了。也许 sourceforge 当时在做

Eugen 的回复Eugen Leitl来源 ↗

现在打不开。

Eugen 引用的中本聪旧信（续）中本聪来源 ↗

维护。

此前的故障报告New Liberty Standard来源 ↗

如果你还不知道，比特币网站打不开了。

http://bitcoin.sourceforge.net/

---

故障报告引用的网站提示Bitweaver来源 ↗

你正在以 TEST 模式运行 bitweaver

• 如果这看起来是应用程序的错误，请点击这里提交错误报告。
• 如果你还没有安装，请到这里开始安装过程。
• 要隐藏这条消息，请将 kernel/config_inc.php 文件中的 IS_LIVE 常量设为 TRUE。

很高兴那样行得通。这些依赖又大又难编译，实在麻烦。有些项目很少顾及 Windows 构建。下次更新到最新版本时，也许我会把所有东西放到同一个目录树里，再把整套内容打包成一个巨大的压缩包。

我不确定他们以前有没有 wxPack。很高兴他们有了它，这样每个人就不必自己编译 wxWidgets 了。OpenSSL 是更难编译的那个。

我通过运行 strip.exe 去掉调试符号，减小了 EXE 的体积。那是用 mingw 编译的。它是更好的编译器，我只用 VC 来调试。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我改用 wxPack，而不是只用 wxWidgets 后，用 MinGW + MSYS 编译成功了。也许需要 wxAdditions。不过 bitcoin.exe 文件有 52MB，我应该看看如何解决。

接下来我准备实现“最小化到托盘”功能，以及随 Windows 自动启动 Bitcoin 的选项，让在线节点的数量保持在更高水平。之后我可以看看能否做 Linux 移植，或网页应用框架需要的命令行接口。

如果你用 IRC，有空来 FreeNode 上的 #bitcoin-dev 看看。

再次感谢你为比特币做的出色工作。

引用 mmalmi@cc.hut.fi：

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我尝试编译第三方库并把它们加入 Bitcoin 构建时，遇到了不少错误。你是否碰巧有一个可以直接编译的包，能上传到 CVS 或其他地方？我用的是 mingw + msys，不过如果更容易的话，我想也可以试试 Visual C++。

我讨厌重复代码，但编译器逼得我们没办法。把它上面那个函数的函数体复制过来，像这样：

    void insert(iterator it, const_iterator first, const_iterator last)
    {
        if (it == vch.begin() + nReadPos && last - first <= nReadPos)
        {
            // special case for inserting at the front when there's room
            nReadPos -= (last - first);
            memcpy(&vch[nReadPos], &first[0], last - first);
        }
        else
            vch.insert(it, first, last);
    }

#if !defined(_MSC_VER) || _MSC_VER >= 1300
    void insert(iterator it, const char* first, const char* last)
    {
        if (it == vch.begin() + nReadPos && last - first <= nReadPos)
        {
            // special case for inserting at the front when there's room
            nReadPos -= (last - first);
            memcpy(&vch[nReadPos], &first[0], last - first);
        }
        else
            vch.insert(it, first, last);
    }
#endif

随信附上了修改后的 serialize.h。

顺便说一句，在我的测试中，VC8 生成的 EXE 只能在安装了 VC8 的系统上运行。它给出的错误提示极其含糊。我想，他们是希望你在安装时再安装一个软件包，但 bitcoin 没有安装程序。

我一直使用 MSVC 6.0 SP6 和 GCC 3.4.5 做测试。正式发布版是用 GCC 编译的。MSVC 6.0 编译出来的版本没什么别的问题，只是它优化后的 SHA 例程在生成区块时运行得慢。

Satoshi

还有附带 gdb.exe 的 gcc 调试版。

引用 Hal 的来信Hal Finney来源 ↗

很遗憾，看起来 0.1.3 在夜里崩溃了。下次我会试着运行调试版。今天我需要工作，会频繁开关这台电脑，所以白天大部分时间都没法让它运行。今晚我会试着花点时间看看。

Hal

这是 0.1.3 的 MSVC 调试版。

引用 Hal 的来信Hal Finney来源 ↗

很遗憾，看起来 0.1.3 在夜里崩溃了。下次我会试着运行调试版。今天我需要工作，会频繁开关这台电脑，所以白天大部分时间都没法让它运行。今晚我会试着花点时间看看。

Hal

2009 年 1 月 12 日（星期一）上午 8:41，Satoshi Nakamoto satoshi@vistomail.com 写道：

引用中本聪前信中本聪2009-01-12来源 ↗

看来0.1.3确实解决了这个问题。之前僵尸节点越来越多，我发出的消息几乎收不到回复。现在，发出4条 inventory 消息，就能收到4条 getdata 消息。

你有没有遇到过显示“未被接受”（not accepted）的区块？如果节点当时无法广播，这个连接问题可能会导致生成的区块不被接受。等状态超过5左右，就可以放心认为它已经被接受了。

可惜，我所在的地方无法接收传入连接，这让事情更困难了。最初一两天，网络主要靠你的节点接收传入连接，才得以持续运转。

如果愿意，你可以向我的比特币地址付款，不过这样你看不到完整的转账过程： 1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD

你也可以运行 findstr /c:"version message" debug.log，然后从列表靠近末尾的已连接用户中随便找一个，试着给他付款。那些以端口8333结尾的节点可以接收连接。

我刚想到一件事。迟早会有人对暴力搜索比特币地址感兴趣，找一个开头几个字符对应自己名字的地址，有点像挑一个能拼出某个词的电话号码。纯属巧合，我这个地址里正好有我的姓名首字母。

Satoshi

引用 Hal 的来信Hal Finney来源 ↗

谢谢，Satoshi，这个新版本似乎运行得好多了。我有8个连接，看 debug.log，似乎有不少活动。我看到你给我付了一笔款，谢谢！告诉我你的地址，我也试着给你付一笔。如果我理解得没错，我昨天成功生成了一个区块，这些币就快成熟了。

Hal

2009 年 1 月 11 日（星期日）晚上 9:31，Satoshi Nakamoto satoshi@vistomail.com 写道：

引用中本聪前信中本聪2009-01-11来源 ↗

我想我已经修复了与“select failed: 10038”（WSAENOTSOCK 错误）有关的问题。select 出错本身不是大问题，但它导致通信线程阻塞在一个套接字上；这个套接字本该处于非阻塞模式，却没有正确设置。这个问题以前一直没有暴露，是因为只要 select 没有失败，只有在有数据可读时才会调用 receive。

如果不修复这个问题，你的节点有时就会停止通信。连接仍会建立，但不会传送数据。生成的区块很可能不会被接受，因为你无法把它们广播出去，其他节点会把你的分支甩在后面。这就是没有网络连接时 Generate（生成比特币）不运行的原因。

这也可能是 bitcoin.exe 无法退出的原因。关闭程序时没有理由等待通信线程，因此我把它改成只等待消息处理线程。以后我会再做更彻底的强制关闭处理。

看起来你的节点的通信线程刚刚又被这个问题阻塞了。这次它运行了几个小时才出问题。

随信附上 0.1.3 版 exe。

好的，谢谢。bitcoin-0.1.1-exe-dbg.rar 里的程序，与 bitcoin-0.1.1.rar 里的是同一次编译生成的版本。

我忘了，用 MSVC 编译调试版本时，它会使用运行时 DLL 的调试版本，而 Windows 系统并不自带这些文件。实际上，MSVC 6.0 的运行时（MSVC60.DLL）是最后一个随 Windows 预装的版本，这也是大家仍然关注那个老版本编译器的原因。较新的 Visual C 版本生成的 EXE 文件需要另装运行时软件包，无法独立运行。

我不能用 MSVC 6.0 来编译正式发布版本，因为它对 SHA-256 例程的优化效果太差，运行得太慢。

随信附上一份调试运行时 DLL。（它们允许再分发。）

引用 Hal Finney 的来信Hal Finney来源 ↗

你好，Satoshi——带 .pdb 文件的那个版本在我这里运行不了，报错说找不到 MSVCP60D.DLL。我想这就是你担心的版本不兼容问题。

接下来那个删掉可疑代码并关闭优化的版本，在我这里似乎运行正常。所以问题可能与那一段有关。

Hal

我定位到问题了。如果我创建一个线程，并在里面调用 mapAddresses.count，哪怕这是程序做的第一件事，也会发生段错误。临时解决办法是在主线程里额外调用一次 mapAddresses.count，此后就一切正常了。我不愿意把问题归咎于编译器，以前也从没遇到过 GCC 编译器的错误，但这次感觉像是。也许是某段初始化代码，如果没有在同一个线程里至少调用一次，就会被它优化掉；也可能是某种不适合多线程的 STL 优化。做了那么多压力测试，发布却被这件事搞砸，实在让我沮丧。

附件 bitcoin-0.1.1.rar（文件大小 2,132,686）是删掉了 mapAddresses.count 那一行的版本，应该是最稳妥的版本。（那是唯一一处调用 mapAddresses.count 的地方。）如果你能试试这个版本，确认崩溃已经修复，我会很感激。

谢谢， Satoshi

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

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

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

故障模块名称： mingwm10.dll

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

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

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

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

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

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

在 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));

}

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

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

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

谢谢。

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

cryptopp/secblock.h:187

//assert(false);

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

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

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

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

它依赖三个时间来源：

1）系统时钟；

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

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

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

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

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

在 debug.log 里搜 "proof-of-work found"。如果搜到了，就看看紧接着有没有报错。

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

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

容许偏差是 2 小时。

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

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

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

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

• 警告：别乱动你的 wallet.dat 文件。它是个数据库文件，没有你想的那么简单。在这个 Beta 版里，我们还没来得及让它在用户自行改动文件时也不容易出问题。如果你把它换来换去，它可能不像预期那样工作。

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

已在 SVN rev 137 完成

我想把状态栏显示的区块数减 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 130 修复。

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

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

不妨试试 0.3.7 版本。

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

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

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

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

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

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

那肯定就是它了。

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

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

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

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

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

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

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

是 120DPI 模式。

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

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

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

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

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

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

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

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

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

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

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

其他参与者原话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 时间来更新显示。

你是双处理器吗？你确定跑的不是只占满一个处理器的程序？

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

更直接的，是这个：

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

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

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

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

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

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

我已把改动上传到 SVN。

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

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

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

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

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

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

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

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

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

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

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

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

有没有人能在 wiki 上写点说明，讲讲如何关闭 Live Protection（无论它完整的正式名称是什么），或是如何给它添加排除项。

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

很快会有针对此问题的 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 广播了一个区块但没人确认收到时。这个警告正是为这种情况准备的：你出于某种原因有连接，但连接已经死了，没人听得到你。你的区块永远不会生效，因为没人收到它。

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

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

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

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

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

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

状态栏的第一格也用于显示菜单项的帮助说明：鼠标悬停在菜单项上时，就会显示对应说明。因为我们所有菜单项的说明都是空白，所以悬停在菜单上时它就被替换成了空白。

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

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

试试：

rename "%appdata%\bitcoin" bitcoin2

那样能行吗？

其他参与者原话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 上没有——这方面并没有什么不同。

现在改 0.3 的功能已经太晚了，但我会把它加进 0.3 之后的待办清单。要不是你指出来，我还真不会注意到这点。

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

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

SVN 已更新。

谢谢测试。

同意。这种小事当然不值得分散用户的注意力。

我改成了每 30 分钟一次。

如果我把频率提高到每 10 分钟一次，它在日志文件中占的篇幅仍然不大。问题只在于 grep 时输出会不会比用户想要的多。

其他参与者原话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 消息每小时一条。你觉得应该多久一次？

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

"这笔交易超过了数据体积限制。你仍可支付 # 的费用发送，

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

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

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

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

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

我以前从没见过它失败。那是一次对 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 是个常量。

它为每个线程设置不同的优先级。生成线程以 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);

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

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

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

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

地址簿现在有 "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 把它再启用回来。

上传了一些 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 版本的人，只是继续折腾构建问题之前，我得先做点有趣的事。

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

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

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

你说得对，我看的是一个有 250,000 个区块的测试运行……真傻。

正常运行时显示内存用量为 17MB，VM 大小为 10MB。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

你有多少内存可用？

VPS 有 320MB RAM，目前空闲 50MB。还有 500MB 交换空间。

引用中本聪此前的文字中本聪来源 ↗

Bitcoin 必然会占用不少内存；在 Windows 上大约 75MB。这会有问题吗？

确定吗？我这里 Windows 任务管理器显示的内存用量约为 13MB。

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

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

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

是的，我把你创建启动文件夹快捷方式的代码放了回去，在 XP 和 Vista 上也都能正常启动。为稳妥起见，我改成让快捷方式设置看起来与我手动创建的完全一致。我把工作目录设为 EXE 所在位置，因为 debug.log 会在那里创建，否则 Windows 会把它放到某个奇怪目录。我还没有修改安装脚本。

我把所有内容都提交到了 SVN（谢谢你把它配置好）

• 多处理器生成
• 每次更改后刷新 wallet.dat，让数据库不再把这些内容留在事务日志里
• 在查看菜单中加入复选项，隐藏所有生成的币，以便只看支付交易
• 禁用手续费选项
• 把最小化到托盘选项做得类似 Firefox 的 MinimizeToTray
• 自 0.1.5 发布以来的其他许多杂项改动

我让程序不再显示未接受的生成币。生成的币至少有一个确认（后面接上一个区块）才会显示，所以通常根本不会看到未接受的币。偶尔，已经显示的生成币可能会消失，因为后来变成了未接受。我想，如果我们不在界面上特意指出，人们不会注意到偶尔发生的未接受。有人告诉我，这些条目永久显示在交易记录中，看着很烦。

我还有更多测试要做。我想，现在我们还得测试 Windows 7 了。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

可能是 Bitcoin 运行后，因为出了问题而退出了。如果是这样，debug.log 应该能提供一些线索。你用的是什么操作系统？我在想，是不是需要管理员权限，而我们没有意识到。在 Vista 上，需要管理员权限的程序无法在系统启动时自动运行。

我用的是 XP。我重新编译了旧版本，这次启动快捷方式能用了。在 Vista 上测试（非管理员）也能用。也许我上次只是漏了什么。

引用中本聪此前的文字中本聪来源 ↗

程序快捷方式有多个设置选项卡，里面有很多小细节。我会试试启动文件夹代码，看看能否复现问题。我电脑上其他所有系统托盘图标对应的程序，都在启动文件夹里，这让用户可以轻松在一个地方管理全部自启动项。注册表项里的那些东西，往往是偷偷藏着的臃肿软件。

我这里正相反，全部启动程序都放在注册表里。不过，如果快捷方式同样好用，对用户来说也许更友好。

可能是 Bitcoin 运行了，但因为某些问题又退出。如果是这样，debug.log 应该能说明一些情况。你用的是什么操作系统？我在想，我们是不是需要管理员权限，却没有意识到。在 Vista 上，需要管理员权限的程序不能在启动时运行。

程序快捷方式的设置有多个选项卡，里面有很多小细节。我会试试启动文件夹的代码，看看能否复现这个问题。我电脑上其他所有系统托盘图标都在启动文件夹里，这让用户能方便地在一个地方管理所有自动运行的程序。注册表项里的那些东西，往往是偷偷隐藏的臃肿软件。

我实现了在每次关闭 wallet.dat 时都将其写入磁盘的代码，这样我们就能告诉用户，他们只需要备份 wallet.dat。你可以只恢复 wallet.dat，其余内容会重新下载。发布前我还得再做一次压力测试。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

嗯，代码能运行，也在启动文件夹里创建了快捷方式。不知为什么，开机时它没有自动启动，但在菜单里点击它时却能正常运行。现在我试着手动创建了一个快捷方式，这次它能自动启动了，不知道为什么。我可以再试试旧代码。

引用中本聪此前的文字中本聪来源 ↗

我找到了，看到你在改用注册表之前，已经提交过启动文件夹的代码。代码中我没看出明显的问题。我想这取决于“默认情况下并不总是工作”具体是什么问题。是 Vista/UAC 安全机制的问题吗？

引用中本聪此前的文字中本聪来源 ↗

启动文件夹里的快捷方式出了什么问题？如果你能把代码发给我，我想再看一遍，看看能否找出问题所在。注册表代码里的第一个 strcat 应该是 strcpy，否则会间歇性失败。如果快捷方式版本用了同样的代码，也许问题就在这里。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我为最新版 Bitcoin 做了一个 Windows 安装程序，其中包括自动启动和最小化到托盘功能。安装程序会创建开始菜单快捷方式和一个启动注册表项。我最初通过在启动文件夹里放快捷方式来实现自动启动，但发现它在默认情况下并不总能工作，最后改用了注册表项。卸载程序会移除这个注册表项，也可以从选项菜单中禁用它，所以我觉得，说到底，它对用户也没有那么大的威胁。

我找到了，看到你在改用注册表之前，已经提交过启动文件夹的代码。代码中我没看出明显的问题。我想这取决于“默认情况下并不总是工作”具体是什么问题。是 Vista/UAC 安全机制的问题吗？

引用中本聪此前的文字中本聪来源 ↗

启动文件夹里的快捷方式出了什么问题？如果你能把代码发给我，我想再看一遍，看看能否找出问题所在。注册表代码里的第一个 strcat 应该是 strcpy，否则会间歇性失败。如果快捷方式版本用了同样的代码，也许问题就在这里。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我为最新版 Bitcoin 做了一个 Windows 安装程序，其中包括自动启动和最小化到托盘功能。安装程序会创建开始菜单快捷方式和一个启动注册表项。我最初是通过在启动文件夹里放快捷方式来实现自动启动的，但发现它在默认情况下并不总能工作，最后改用了注册表项。卸载程序会移除这个注册表项，也可以从选项菜单中禁用它，所以我觉得说到底，它对用户也没有那么大的威胁。

谢谢。我还在合并一些自己的改动，这些需要在下一次发布前纳入。有些改动来自收到的问题和反馈，可以减少困惑。我大概会启用多处理器生成支持，也希望能做到，只备份 wallet.dat 就能安全备份资金。又能写代码了，真好！

我准备隐藏手续费设置，它完全没有必要，只会让人困惑。它原本只是用于测试和演示一个技术细节，这个细节即使会用到，也只是很遥远的未来才需要；但必须从一开始实现，才能让以后成为可能。

启动文件夹中的快捷方式出了什么问题？如果你能发来代码，我想再看看，能不能找出问题。注册表代码中的第一个 strcat 应该是 strcpy，否则会间歇性失败。如果快捷方式那部分也用了同样的代码，也许问题就在这里。

看到更多人产生兴趣，比如那个 NewLibertyStandard 网站，让人受到鼓舞。我喜欢他根据电力估算价值的方法。看看人们接受哪些解释，很有启发。他们可能帮助我们发现一种简化的理解方式，让大众更容易接受。世界上许多复杂概念，都有一个能让 80% 的人满意的简单解释；对于另外 20% 能看出简单解释缺陷的人，则有一个让他们满意的完整解释。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我给最新版 Bitcoin 做了一个 Windows 安装程序，包含自动启动和最小化到托盘功能。安装程序会创建开始菜单快捷方式和启动注册表项。我最初用启动文件夹中的快捷方式实现自启动，但发现默认情况下并非总能正常工作，最后改用了注册表项。卸载程序会删除该注册表项，也可以在选项菜单中禁用，所以我觉得它对用户终究不算什么大麻烦。

我用 NSIS 做了安装程序，nsi 脚本在 SVN 里。

你能把安装程序加到 SF 下载页吗？文件在这里： http://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe

bitcoin.sf.net 网站注册了一些新用户。其中一个刚宣布，他在用美元交易比特币。这是他的网站：http://newlibertystandard.wetpaint.com/。最初觉得， 现在做兑换服务有点过早，但另一方面，有人对项目感兴趣是好事，这也许能吸引更多感兴趣的人（希望也包括更多开发者）。我刚给他发了封邮件。

太好了，这是很好的进展。

是的，我解决了 SourceForge 登录问题。登录页上的某个复杂设计触发了浏览器插件中一个古怪的错误。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

告诉你一声：我把工作副本提交到了 svn/branches。里面有最小化到托盘功能和其他一些改动。现在后台运行更方便了，但还没做完，我还在继续。错误列在 bugs.txt 中。

你的 SourceForge 账户能用了吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

接下来我准备实现“最小化到托盘”功能，以及随 Windows 自动启动 Bitcoin 的选项，让在线节点的数量保持在更高水平。

现在想来，你指出了目前最重要的缺失功能，它能让节点数量产生数量级的变化。没有自动运行，我们几乎不可能在用户最初出于兴趣试用后把节点留下来。默认自动运行并最小化为托盘图标，是早期文件共享网络成功的关键。对于 v0.1.0 来说，这样做还不合适，因为当时稳定性没有保证，但现在已经很好、很稳定了。这是下一版本必须具备的功能；这样，如果有用户回来试用新版本，希望这次能留住他们。

我认为，对用户最友好的自动运行方式，是在 Startup 文件夹里放一个图标。我看到自己电脑上的 OpenOffice.org 和其他一些软件都这么做。另一种方法是创建一个 runas 注册表项，用户不容易看到或编辑，我一直不太喜欢。我想我们需要一个默认开启的自动运行选项，当选项发生变化时，就创建或删除启动图标。

虽然做 Linux 移植很诱人，但一旦做了，以后每次发布都要承担这份额外工作。我宁愿再推迟一段时间。自动运行可能带来 300% 的额外节点，而 Linux 可能只带来 3%。Linux 会帮助服务器集群，但实际上我们更想照顾个人用户。有人报告说，它在 WinE 中运行良好。

肯定是磁盘满了。我之前打算把磁盘空间不足的处理全部留到后续版本再做。看来现在差不多该做了。

好了，这下我放心了。

Satoshi

引用 Hal 的来信Hal Finney来源 ↗

你好，Satoshi——抱歉今天没能多做一些，看起来我这周会很忙。这次我又在 MSVC 调试器下启动了 0.1.3，如果今晚它再次崩溃，我也许能拿到更多信息。

我现在想起来了，昨晚我的磁盘满了。我下载了一些依赖库（boost 等），打算试着自己编译，而我的磁盘本来就已经很满了。我很确定，这就是导致 0.1.3 崩溃的原因。我附上了 debug.log，里面还包括另外几次运行的记录。错误出现在日志大约三分之一的位置，内容是：

EXCEPTION: NSt8ios_base7failureE CAutoFile::read : end of file

以如今大家使用的磁盘容量来说，正常情况下这种事应该很少发生。

Hal

2009 年 1 月 12 日，Satoshi Nakamoto satoshi@vistomail.com 写道：

引用中本聪前信中本聪2009-01-12来源 ↗

你能把 0.1.3 崩溃时的 debug.log 发给我吗？通常只看这个文件，我就能得到很多信息。

我很快就把调试版发给你。

引用 Hal 的来信Hal Finney来源 ↗

很遗憾，看起来 0.1.3 在夜里崩溃了。下次我会试着运行调试版。今天我需要工作，会频繁开关这台电脑，所以白天大部分时间都没法让它运行。今晚我会试着花点时间看看。

Hal

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

0.3.13 RC1 的 Windows 版已可用：

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

这在 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 " 命令。它会锁定钱包并拷贝，因此你能确定拿到的是正确的副本。

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

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

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

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

直接返回 "" 就好。

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

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

我想我们应该试着支持没有 Content-Length 参数的情形。不过，即使不得不逐个字符读取，我也不想把现有的流处理机制全部换掉。

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

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

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

SVN rev 111

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

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

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

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

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

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

其他参与者原话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。

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

显然，重复头部是个 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 是否正确，再去修它。

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

如果我没记错，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 时才该报错警告。如果不需要密码，就应该没事。是这样吗？

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

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

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

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

其他参与者原话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=<password>

", "Bitcoin", wxOK | wxICON_EXCLAMATION);

#else

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

");

#endif

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

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

其他参与者原话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" 也不能怪人家。

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

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

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

# comment

setting=value

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

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

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

不要在用来浏览网页的机器上使用 -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 参数列表里却是第一个。我同意从文件里读命令行密码会更方便、更安全。

你也把我绕晕了，什么意思？我做了什么非预期的改动吗？

对，那样确实好不少。

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

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

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

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

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

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

如果你对开关的名字有更好的想法，告诉我，但请记住将来数据库加密也需要一个密码。我不确定，但我想用户可能会希望为这两种用途设置不同的密码。

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

现在所有命令都要把密码作为第一个参数。运行 "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

其他参与者原话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。

我这就着手加密码字段。

欢迎，Harry。

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

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

过去一个半月，我也一直在忙其他事情。我刚刚才把 4 月初以来的邮件下载下来。大多数事情已经处理妥当，应该很快就能回到比特币上来。很高兴我不在时你一直在处理各种事务。祝贺你完成了第一笔交易！

我记得，代码已经差不多可以发布 0.3 版了。我想只需要再测试一段时间，并安装新的图标 xpm 文件。

JSON API 函数已经完成。我想再用新鲜的眼光看一遍，看看提交之前能否想到更好的函数名。我应该写些示例代码，展示它们的正确用法，尤其是如何轮询已收到的交易。我停下来时，正在考虑给一个免费的上传服务器软件加上支付机制，作为示例。在发布 API 之前，实际用它构建一个实用应用，是合理的。只有真正尝试使用 API，才会发现它的问题。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

你好！

最近怎么样？有一阵子没见到你了。

我最近一直在做全职工作，而且会持续到 6 月底，所以没有太多时间做 Bitcoin 或我的兑换服务。不过我的服务已经有一个能工作的 beta 版，几周前还完成了第一笔交易：通过欧盟银行转账，以 20 欧元卖出 10,000 btc。也许很快就能公开。

我把论坛分成了 6 个版块，分别是比特币讨论、开发与技术讨论、技术支持、经济、市场和交易讨论。希望这样没问题？

我还在 bitcoin.org 网站上添加了一个“Trade”页面，列出了接受 btc 的服务。很高兴已经有一些有用的服务接受 btc。

社区一直在良好发展。最近 #bitcoin-dev 大约有 10-20 人，讨论很活跃。

如果能把可作为守护进程运行的二进制程序放到 SF.net 就好了。我们社区现在有一些熟练的程序员，所以如果你没时间，也许我们可以完成 JSON API 函数。

祝好。

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 这类脚本语言里，语法就像调用本地函数一样自然。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我找到了一些关于让同一二进制文件无图形界面运行的线索：

1. GTK 支持在没有显示的情况下运行程序： http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check. 不过这并没有说明在 wxWidgets 中是否可行。

我看到它在 wxApp::Initialize 中调用了 gtk-init-check。

我可以在子类中重写 Initialize，抑制错误消息后调用原来的函数，并忽略返回值。看来可以运行。

对于命令行开关的名称和说明，有什么建议吗？有没有惯用的标准？我目前用的是： -daemon（或 -d） （启用 RPC，并在后台运行） -server （启用 RPC）

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

你不是有一台 Ubuntu 笔记本，可以用来测试和编译，不必折腾 VPS 吗？

是的。用 Python 的 JSON-RPC 测试了，似乎工作正常！使用起来真的很简单。

太好了，第一次就成功了。

能把你用的 Python 代码发给我吗？这样如果以后我要做些测试，就不必自己再摸索了。

我把 JSON-RPC 和命令行实现上传到了 SVN。我想多花些时间考虑命令，再发到论坛。至少有一些方法名还会改变。

要启用 RPC 服务器，请添加 -server 开关。默认不启用。

客户端命令不带任何开关，像这样：

bitcoin getblockcount
bitcoin getdifficulty
bitcoin getnewaddress somelabel
bitcoin sendtoaddress 1DvqsbZ... 1.00
bitcoin getallpayments 0
bitcoin stop

应用程序通常会直接使用 JSON-RPC，而不是命令行。

我还没用其他程序测试过自己的 JSON-RPC 服务器。如果你测试了，请告诉我结果。你用的是 Python，对吧？

让 Linux 版在未安装 GTK 时运行，是另一项独立任务。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

太好了！我会开始熟悉 Liberty Reserve 及其 API。

引用中本聪此前的文字中本聪来源 ↗

JSON-RPC 实现进展顺利。我用 boost::asio 处理套接字。JSON-RPC 可以使用普通套接字或 HTTP，但似乎大多数其他实现都用 HTTP，所以我自己做了简单的 HTTP 头。 JSON 解析用的是 JSON Spirit，它充分使用 STL，用起来很好。它只有头文件，不增加构建工作，而且足够小，可以直接放入我们的源码树。采用 MIT 许可证。再过几天，这些应该都能运作了。

论坛确实热闹起来了。我没想到这么快就会有这么多活动。

JSON-RPC 的实现进展顺利。我用 boost::asio 处理套接字。JSON-RPC 可以用普通套接字或 HTTP，但其他大多数实现似乎都用 HTTP，所以我写了自己的简单 HTTP 头。 JSON 解析我用的是 JSON Spirit，它充分使用 STL，一直很好用。它只有头文件，不会增加构建工作，体积也足够小，可以直接放进我们的源代码树。MIT 许可证。再过几天，应该就能全部运行起来了。

论坛确实发展起来了。我没想到这么快就有这么多活动。

我在 wxSocketServer::Accept(bool wait = true) 的文档中注意到这段：

文档引文wxWidgets 文档来源 ↗

“如果 wait 为 true，且没有待接受的连接，它会等待下一个入站连接到达。**警告：这会阻塞 GUI。”

wxWidgets 对单线程的要求简直到了病态的程度。不仅要求单线程，还必须是 GUI 线程。连 wxStandardPaths 这么与界面无关的东西，我都栽了跟头。这些对界面代码倒没问题，因为 Windows 本来也施加同样的限制；但对于没有界面的服务器守护进程代码，wx 调用就不可靠了。

我目前的研究进展：

要让 PHP、Python 等访问服务器，我们需要使用普通套接字。我想，可以只绑定 localhost，让它只能通过回环接口访问，从而限制为本机使用。他们说，简单检查收到的连接的 IP，断开所有不是 127.0.0.1 的连接，也同样严密。不妨两种都做。

XML-RPC 有点臃肿。C++ 有 4 个库，但都很大，难以构建，还有依赖和许可证问题。一些发帖者抱怨，所有 C++ 和 PHP 的 XML-RPC 库都有很多错误。

JSON-RPC 是一种更简单、更优雅的标准。它足够简单，我可以使用通用 JSON 解析器。

PHP、Python 和 Java 都有不错的 JSON-RPC 实现。

我目前倾向于 JSON-RPC。

很好，那就不用考虑 d-bus 了。Windows 上有没有类似 IPC 套接字的东西？我想我们可以看看 wx 是怎么做的，也许 XML-RPC 库已经知道该怎么处理。Windows 有命名管道，也许那是最接近的对应物。

我想我不愿意发明自己的 RPC 协议，而是想用一个现有标准。PHP、Java、Python 或其他任何语言，都可以像命令行命令一样，直接与服务器通信。

我准备开始阅读 XML-RPC 的资料。搜索结果显示，它是使用最广泛、支持也很普遍的协议。PHP 的标准库里就包含它。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

引用中本聪此前的文字中本聪来源 ↗

能否打开一个只能本地访问的套接字？

可以，IPC 套接字（“Unix domain sockets”）就只能在本地使用。在 wx-api 中，用文件名代替端口号就能做到。我提交了一个 wxServer-Client 通信用法的示例，你愿意的话可以撤销。现在有一个 -blockamount 命令行选项，会向运行中的实例询问区块链长度。

我认为这种命令行方式已经可以从 PHP 调用，但如果 php 自己能直接调用套接字服务器，可能会更轻量。 wx 的 IPC 概述提到 wxSocketEvent、wxSocketBase、 wxSocketClient 和 wxSocketServer 是“底层 TCP/IP API 的类”，从 php 使用它们，可能比我现在用的（wxServer、wxClient、wxConnection）更容易。我会进一步研究。

有没有办法查明缺少的是哪些共享库？知道这一点会有帮助。

可能需要 GTK 库，如果是这样，64 位版也会有同样问题。我希望只有一个可执行文件，而且也能在没有界面的系统上运行，但不确定在 Linux 上，如何链接某些库，同时在库不存在时仍能运行、只是不使用它们。也许我们应该静态链接 GTK。许可证方面，它采用 LGPL，但因为只在 Unix 上使用，所以没问题。（Windows 上不能链接 LGPL 的东西，因为我们提供 OpenSSL DLL；但 Linux 上 OpenSSL 是操作系统自带的。）

附件是我的 64 位可执行文件（已去除调试信息）。其中包含尚未测试、还没提交到 SVN 的修改：界面改动，以及钱包 fSpent 标记的重新同步相关内容。

我一直在研究进程间调用方案。我希望各种服务器端语言，尤其是 PHP，都能轻松调用它。如果还能跨平台支持 Windows，就更好。

我还不确定是否希望它能够通过网络访问。那会带来安全问题。如果只能在本机访问，本地安全认证就能覆盖它，也就不可能被远程攻破。

目前只粗略了解，还没深入细节，领先的候选方案有： D-Bus： 仅限本机 qt、gnome 和 skype 都在使用 语言绑定：c、python、java、c++， php 列为“进行中” .net 列为无人维护 不确定在 Windows 上成熟到什么程度 XML-RPC： 使用广泛，PHP 有内置库 更偏向 Web 客户端与服务器通信，传输使用 HTTP，所以有安全问题

能不能打开一个只允许本机访问的套接字？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

你决定 Bitcoin API 使用哪种进程间调用方法了吗？一个简单方案是 wxWidgets 提供的套接字接口： http://docs.wxwidgets.org/trunk/overview_ipc.html。让 Bitcoin 程序运行 wxServer，然后就能从命令行调用 bitcoin 可执行文件来访问，或者自己编写 wxClient 应用。

另一个选择是直接使用普通 BSD 套接字。

如果你有 64 位 Linux 的 Bitcoin 二进制文件，能发给我吗？我试过在 VPS 上编译，但内存耗尽了。也试过 32 位版本（配合 ia32-libs），但找不到共享库。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我至少还需要命令行工具，来检查是否收到币，以及发送币。这需要某种方式，与后台运行的比特币进程通信。我不知道应该怎么做，也许与 RPC 有关。

如果后台进程没有图形界面，也会很好—— 目前这个服务档位的 VPS 没有足够内存运行 X 窗口环境，除非我能想办法释放内存。

我之前一直纳闷，为什么大家总是强调无界面，明明已经可以让程序只在托盘里显示一个小图标运行，而这对 Windows 上的服务器服务很常见。我想原因就在这里。我原先还以为，如果他们连一个从来不会看的桌面上的小图标都受不了，那是 unix 用户的优越感在作怪。

不打开任何窗口很容易，不过可能因为没有 gtk 库而失败。wxWidgets 有 WXBASE，表示“仅 wxBase，不含图形界面功能”。你可以尝试用它代替 WXGTK 来编译，看看会怎样。如果有办法用同一个可执行文件的命令行开关实现，会更好，而不必再多发布一种构建变体。

你可用的内存有多少？比特币必然要占用不少内存，在 Windows 上大约 75MB。这会有问题吗？

命令行控制是接下来要做的事情之一。我想仔细设计 API。

接收付款这部分有很多设计选择要做。调用方需要识别自己关心的交易，这正是每笔交易使用一个比特币地址的模式能发挥作用的地方。另一种可能是从备注文本中搜索订单号。可以采用轮询，询问指定比特币地址收到了哪些付款，也可以采用事件驱动。我想，事件驱动方式就是告诉比特币：当某个比特币地址收到特定金额时，运行一条命令行。

到时候会有运行时的命令行开关让它无 UI 运行。它要做的只是不创建主窗口。一个简化的做法是把 ui.cpp 里的 "pframeMain->Show" 和 "ptaskbaricon->Show" 禁掉。网络线程并不在乎 UI 在不在。UI 方面仅剩的另一处，是 CheckDiskSpace 里磁盘空间不足时的消息框。

然后配一个独立的命令行工具与它通信、执行操作。名字还没想好。

"自然通缩"——这名字我喜欢。是的，付款失误与数据丢失，会造成自然通缩。新币产出的速度最终会降到低于自然通缩的速度，届时就会出现净通缩。

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

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

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

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

用 DB_PRIVATE 20 分 51 秒

不用 DB_PRIVATE 20 分 51 秒

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

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

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

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

DB_PRIVATE 是两头不讨好的东西。它并不保证独占访问，但一旦另一个进程试图同时访问，数据库就会出问题。

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

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

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

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

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

我通常躲着 iostreams。我似乎经常碰到它的限制。他们 90 年代把 C++ 流标准搞得一团糟，真遗憾，流机制如果设计得当，可以非常强大实用。在 rpc.cpp 里用它最终恐怕也会被证明是个错误。

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

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

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

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

谢谢。我就觉得里面应该有这个功能。

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

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

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

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

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

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

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

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

看来，DB_PRIVATE 并没有做到你期望它做的事，也就是阻止其他进程打开数据库。它照样允许访问，只是一旦其他进程真的打开数据库，就会出问题。如果有办法实现，另一种选择是锁定数据库文件，使其他进程无法访问。

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

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

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

我讨厌重复造轮子，是不得已才自己写序列化例程的。我们现有的序列化格式尽可能简单、扁平。输入流的构成方式没有任何多余的自由度。读取到任何位置时，下一个字段都符合预期的数据结构。允许的变化也都在接收方的预期之内。有版本号，所以可以升级。

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

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

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

我替换掉了 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 构建，需要有人检查一下。

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

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

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

1.139999999999 的小数位数超出了 bitcoin 内部能表示的精度。

内部只可能是：

1.13999999 或

1.14000000

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

代码是这样的：

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

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

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

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

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

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

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

扫兴了，抱歉。

问题在 util.c 的 ParseString 中。我猜是“unsigned int”类型与 str.npos 的类型不兼容，后者是 size_type。

试着把两处“unsigned int”改为“size_type”。

原来：

void ParseString(const string& str, char c, vector<string>& v)
{
     unsigned int i1 = 0;
     unsigned int i2;
     do
     {
         i2 = str.find(c, i1);
         v.push_back(str.substr(i1, i2-i1));
         i1 = i2+1;
     }
     while (i2 != str.npos);
}

改为：

void ParseString(const string& str, char c, vector<string>& v)
{
     size_type i1 = 0;
     size_type i2;
     do
     {
         i2 = str.find(c, i1);
         v.push_back(str.substr(i1, i2-i1));
         i1 = i2+1;
     }
     while (i2 != str.npos);
}

引用 Martti Malmi 的文字Martti Malmi来源 ↗

这是我用 gdb 调试时另一次测试运行得到的 debug.log。程序在调试行“irc 8”之后开始吞噬内存，几秒钟内就崩溃了，显示“terminate called after throwing an instance of 'std::bad_alloc'”。

引用中本聪此前的文字中本聪来源 ↗

问题在 RecvUntil 中，但我还是看不出它哪里有错。我唯一能想到的，是套接字可能在接收大量不断涌入的字符。

试试这个 irc.cpp。debug.log 可能会迅速增长，做好终止程序的准备。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

附上 debug.log

引用中本聪此前的文字中本聪来源 ↗

这样就把范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它应该还没执行完 RecvUntil。粗看没有发现明显问题。我想问题只能出在 ConnectSocket 或 RecvUntil 中。

试试附件中的 irc.cpp 和 net.cpp，然后把 debug.log 发给我。

或者你可以在 gdb 中运行它，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或者用 u 单步跳过，并退出子程序。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

不管是否执行 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题就解决了。

引用中本聪此前的文字中本聪来源 ↗

如果你不执行 getinfo，它还会这样吗？

你可以把下面列出的 CreateThread 调用注释掉，然后逐个重新启用，直到它再次出问题。这样我们就知道问题在哪个线程里了。

net.cpp 中，// Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)

init.cpp: CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃时的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，但 还没取得多少进展。它总会占满系统的全部内存，最后崩溃。能否请你再次把最新的 64 位 bitcoind 构建发给我，让我看看问题是否出在自己编译的版本上？

test 7：

运行之前请备份数据目录，以防万一。

针对 Db::open/Db::close 的“Bad file descriptor”异常的临时解决办法。它也可能让初始区块下载更快。做法是打开数据库句柄，并在程序的整个运行期间保持打开，这其实本来就是更常见的做法。如果我们不再不停地关闭和打开，错误就应该没有机会发生。

唯一的例外是 wallet.dat，我仍会在写入完成后关闭它，以便将事务日志写入 dat 文件，让 dat 文件能够独立使用。这样，如果有人在 Bitcoin 运行时备份，得到的 wallet.dat 本身就是有效的，无需数据库事务日志。

这是对数据库处理方式的重构，所以我们可能会发现一些新的死锁。通常如果出现死锁，要么界面停止重绘，要么虽然仍显示 Generating，却不再使用 CPU。

我想到一个临时解决办法，但要看错误出在哪些文件上。如果 db.log 已经积累了几条错误，能把它发给我吗？（即使内容很简单、很无聊。）列出的文件是否总是 blkindex.dat，还是也包括 addr.dat 或 wallet.dat？

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我把数据目录移回 SSD 卡，并启动了 bitcoin test 6。它今天发生了段错误，日志里有 Db::open。当时我把设置改成只用一个处理器/核心，一边观看一部 720p mkv 电影。电影结束后，我才注意到段错误。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

这个版本用了另一种方式链接 Berkeley DB。值得一试。其他方面与 test5 相同。

（请至少先把 datadir 放在硬盘上，直到你也在那里复现相同的失败。这样成功的机会不小。）

这是一个小版本更新，增加了一些 DoS 防护。

改动：

• 增加了一些 DoS 限制，不过距离抵御 DoS 还很远。
• 移除了“安全模式”警报。

http://www.bitcoin.org/smf/index.php?topic=2228.0

下载： http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

这是一个小版本更新，增加了一些 DoS 防护。

改动：

• 增加了一些 DoS 限制，不过距离抵御 DoS 还很远。
• 移除了“安全模式”警报。

http://www.bitcoin.org/smf/index.php?topic=2228.0

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

自动附加的广告与页脚邮件列表系统来源 ↗

---

Oracle 转换到 DB2 指南：了解对 PL/SQL 的原生支持、新数据类型、标量函数、改进的并发处理、内置包、 OCI、SQL*Plus、数据迁移工具、最佳实践及更多内容。 http://p.sf.net/sfu/oracle-sfdev2dev

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

0.3.18 版本现已可供下载。

改动：

• 修复了从 0.3.17 降级后再升级时出现的 wallet.dat 兼容性问题
• 加入 IsStandard() 检查，使区块仅包含已知交易类型
• Jgarzik 的优化，使首次区块下载稍快一些

这个版本的主要新增内容，是 Gavin 一直在开发的基于账户的 JSON-RPC 命令（更多详情见 http://www.bitcoin.org/smf/index.php?topic=1886.0）。

• getaccountaddress
• sendfrom
• move
• getbalance
• listtransactions

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

0.3.18 版本现已可供下载。

改动：

• 修复了从 0.3.17 降级后再升级时出现的 wallet.dat 兼容性问题
• 加入 IsStandard() 检查，使区块仅包含已知交易类型
• Jgarzik 的优化，使首次区块下载稍快一些

这个版本的主要新增内容，是 Gavin 一直在开发的基于账户的 JSON-RPC 命令（更多详情见 http://www.bitcoin.org/smf/index.php?topic=1886.0）。

• getaccountaddress
• sendfrom
• move
• getbalance
• listtransactions

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

自动附加的广告与页脚邮件列表系统来源 ↗

---

这封 SF Dev2Dev 邮件的赞助方为：

自动附加的广告与页脚邮件列表系统来源 ↗

WikiLeaks：自由互联网的终结
http://p.sf.net/sfu/therealnews-com

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

变更：

• 修复了从 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/

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

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/

0.3.15 版现已发布。

变更：

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

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：

• 俄语翻译

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.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

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

这是 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 候选发布版，请测试：

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

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

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

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/

其他参与者原话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.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/

这是测试版构建，如果你想在 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

rev 130 的杂项修复：

修复相对路径 -datadir

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

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

修复 linux 构建的 readlink 编译警告

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

-paytxfee 开关，比如 -paytxfee=0.01

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 或更老的机器吗？

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

编辑：SourceForge 现在更新了。

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

新功能：

• Gavin Andresen 的 HTTP 认证，保护 JSON-RPC
• 初始区块下载速度达到原来的 5 倍，30 分钟以内

请测试 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

谢谢！

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

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

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

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

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

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

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

下载链接在 bitcoin.org

更新内容：

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

Windows

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

Linux

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

宣布发布点对点加密货币比特币的 0.3 版本！比特币是一种数字货币，使用密码学和分布式网络，取代对可信中央服务器的需要。摆脱集中管理货币被任意增发的风险！比特币的流通总量限定为 2100 万枚。这些币会根据网络节点贡献的 CPU 算力，逐步发行给节点，所以你可以贡献闲置 CPU 时间，获得其中一份。

新变化：

• 命令行和 JSON-RPC 控制
• 包含无图形界面的守护进程版本
• 交易筛选标签页
• 哈希速度提高 20%
• 哈希速度性能显示
• Mac OS X 版本（感谢 Laszlo）
• 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

前往 http://www.bitcoin.org 获取，阅读论坛了解更多。

宣布推出点对点加密货币 Bitcoin 的 0.3 版！比特币是一种数字货币，使用密码学和分布式网络，取代对可信中央服务器的需求。摆脱集中管理货币的任意通胀风险！比特币总流通量限制为 2100 万个币。这些币根据网络节点贡献的 CPU 算力，逐步发行给节点，因此贡献空闲 CPU 时间，就能获得其中一份。

新内容：

• 命令行与 JSON-RPC 控制
• 包含无 GUI 的守护进程版本
• 交易筛选选项卡
• 哈希计算提速 20%
• 哈希速率性能显示
• Mac OS X 版（感谢 Laszlo）
• 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

在 www.bitcoin.org 获取，并阅读论坛以了解更多。

自动附加的广告与页脚邮件列表系统来源 ↗

---

这封 SF.net 邮件由 Sprint 赞助拿到首款 4G 手机 EVO，你首先会做什么？访问 sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

其实，如果原来连这个功能都没有，“已发送和已接收交易的标签页”听起来会很不成熟。“交易筛选标签页”更好听。

我还会再稍微编辑一下，然后发邮件到 bitcoin-list 和密码学邮件列表。

“在 http://www.bitcoin.org 获取，或阅读论坛了解更多。”

引用中本聪此前的文字中本聪来源 ↗

我把 0.3.0 beta 上传到了 sourceforge，并更新了 bitcoin.org 上的链接。我还需要在论坛和邮件列表发布公告。下面是我准备的内容：

宣布点对点加密货币比特币 0.3 版发布！比特币是一种数字货币，用密码学和分布式网络取代对可信任中央服务器的需要。摆脱中央管理货币随意通胀的风险！比特币总流通量限定为 2100 万枚。这些币正在根据网络节点贡献的 CPU 算力，逐步分配给它们。只要安装软件，贡献闲置的 CPU 时间，你就能分得其中一份。

新增内容：

• 命令行和 JSON-RPC 控制
• 包含没有 GUI 的守护进程版本
• 已发送和已接收交易的标签页
• 哈希运算提速 20%
• 哈希速率性能显示
• Mac OS X 版本（感谢 Laszlo）
• 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

我把 0.3.0 beta 上传到了 SourceForge，并更新了 bitcoin.org 上的链接。还需要在论坛和邮件列表发布公告。下面是我准备的内容：

宣布推出点对点加密货币 Bitcoin 的 0.3 版！比特币是一种数字货币，使用密码学和分布式网络，取代对可信中央服务器的需求。摆脱集中管理货币的任意通胀风险！比特币总流通量限制为 2100 万个币。这些币正根据网络节点贡献的 CPU 算力，逐步发行给节点。只要安装软件，贡献空闲 CPU 时间，你就能获得其中一份。

新内容：

• 命令行与 JSON-RPC 控制
• 包含无 GUI 的守护进程版本
• 已发送和已接收交易选项卡
• 哈希计算提速 20%
• 哈希速率性能显示
• Mac OS X 版（感谢 Laszlo）
• 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

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

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

好，那还是回到 0.3。

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

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

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

（已回退到 rc2）

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

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

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

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

（链接已移除，见下）

使用 irc.lfnet.org。

这是供测试的 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。

这是供测试的 windows 版 RC1：

（已移除，见下方 RC2）

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

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

现在如果有人帮忙测试，我会非常感激。

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

比特币 0.2 来了！

下载（Windows，以及现已提供的 Linux 版本） http://sourceforge.net/projects/bitcoin/files/

新功能

Martti Malmi

• 最小化到系统托盘的选项
• 开机自动启动的选项，让程序能够自动在后台持续运行
• 新的选项对话框布局，方便未来扩展
• Windows 安装程序
• Linux 版本（已在 Ubuntu 上测试） Satoshi Nakamoto
• 生成功能支持多处理器
• 支持代理，可配合 TOR 使用
• 修复了首次区块下载的一些速度问题

我们还有了一个新论坛：http://www.bitcoin.org/smf/

非常感谢 Martti（sirius-m）完成的全部开发工作，也感谢 New Liberty Standard 帮忙测试 Linux 版本。

Satoshi Nakamoto

比特币 0.2 来了！

下载（Windows，现在也有 Linux 版本）
http://sourceforge.net/projects/bitcoin/files/

新功能

Martti Malmi

• 最小化到系统托盘选项
• 开机自动启动选项，让它可以自动保持在后台运行
• 新的选项对话框布局，便于未来扩展
• Windows 安装程序
• Linux 版本（已在 Ubuntu 上测试） Satoshi Nakamoto
• 生成币时支持多处理器
• 支持代理，以便配合 TOR 使用
• 修复了初始区块下载过程中的一些缓慢问题

我们还有了一个新论坛：http://www.bitcoin.org/smf/

非常感谢 Martti（sirius-m）所做的全部开发工作，也感谢 New Liberty Standard 帮助测试 Linux 版本。

Satoshi Nakamoto

自动附加的广告与页脚邮件列表系统来源 ↗

---

这封 SF.Net 邮件由 Verizon 开发者社区赞助利用 Verizon 一流的应用开发支持简化的 14 天上市流程，让应用分发快捷方便现在加入，离数百万 Verizon 客户更近一步 http://p.sf.net/sfu/verizon-dev2dev

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

这是拟用的版本发布公告文本。大概很快就会发布。

Bitcoin 0.2 版来了！

下载链接： Windows 安装程序 Windows Zip 文件 Linux（已在 Ubuntu 上测试）

新功能

Martti Malmi

• 最小化到系统托盘选项
• 开机自启动选项，可让程序自动持续在后台运行
• 新的选项对话框布局，便于未来扩展
• Windows 安装程序
• Linux 版 Satoshi Nakamoto
• 生成币时支持多处理器
• 支持代理，可配合 TOR 使用
• 修复初次下载区块时的部分速度问题
• 多项改进，维持网络顺畅运行

我们还在 http://www.bitcoin.org/smf/ 建立了新论坛，有任何问题都可以来。

感谢 Martti Malmi（sirius-m）的编程工作，以及对新网站和论坛的托管；也感谢 New Liberty Standard 测试 Linux 版。

Satoshi Nakamoto

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 版。

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

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

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

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

宣布比特币发布。这是一种新型开源点对点电子现金系统，完全去中心化，没有中央服务器或可信任方。用户自己掌握其资金的密码学密钥，并直接相互交易，借助 P2P 网络检查双重支付。

Windows NT/2000/XP/Vista。包含开源 C++ 代码。

下载：http://www.bitcoin.org

• 将文件解压到一个目录
• 运行 BITCOIN.EXE
• 它会自动连接其他节点

如果你能持续运行一个接受传入连接的节点，就能为网络提供很大帮助。你需要开放防火墙的 8333 端口，才能接收传入连接。

你可以让别人给你一些币，或打开 Options->Generate Coins，运行节点并生成区块。我把初始工作量证明难度设得低得离谱，所以刚开始的一小段时间里，普通 PC 只需几小时就能生成币。当竞争使自动调整机制提高难度时，就会困难得多。生成的币必须等待 120 个区块，成熟后才能花费。

有两种汇款方式。如果收款人在线，你可以输入他的 IP 地址，软件就会连接过去，获取一个新公钥，并发送附有备注的交易。如果收款人不在线，你可以向他的比特币地址付款，这个地址是他提供给你的公钥哈希。下次他连接网络，获取包含该交易的区块时，就会收到这笔交易。这种方式的缺点是不传送备注信息，而且如果一个地址被多次使用，可能损失一点隐私；但如果双方无法同时在线，或收款人不能接收传入连接，它就是一种有用的替代方式。

总流通量将为 21,000,000 枚币。它们会在网络节点创建区块时分配给节点，分配数量每 4 年减半。

最初 4 年：10,500,000 枚币接下来 4 年：5,250,000 枚币接下来 4 年：2,625,000 枚币接下来 4 年：1,312,500 枚币依此类推……

这些币发完后，系统可以在需要时支持手续费。这基于公开的市场竞争，而且很可能始终会有节点愿意免费处理交易。

Satoshi Nakamoto

http://www.bitcoin.org

0.1.5 版本现已可用。它修复了 Nicholas 遇到的问题，增加了磁盘空间已满的检查，并作出了一些修改，尝试改善让人困惑的地方。

特别感谢 Nicholas 和 Dustin 提供的所有帮助与反馈！

下载链接： http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441

改动：

• 磁盘空间已满警告
• 修复了 DNS 查询失败时可能发生的一个错误
• 阻止在地址簿中输入自己的地址， 因为这会改变自己地址的标签，令人困惑
• 将更改地址按钮移到选项菜单下
• 调整了连接过程，使连接更快建立
• 退出时关闭套接字
• 为少于 1 分的交易设定最低手续费
• 隐藏了只有一个选项的交易类型选择框
• 稍微整理了 ParseMoney
• 将消息文本的格式整理得稍微清晰一些
• 更改了交易详情对话框的字体
• 在生成币的交易详情中添加了一些说明文字
• 改写了通过比特币地址收到的交易的描述

Satoshi Nakamoto http://www.bitcoin.org

看来最严重的互联网连接问题已经解决了。0.1.3 修复了一个会导致节点通信在一段时间后停止的问题。使用这个版本后，网络运行顺畅多了。

如果你成功生成过一个区块，就会看到它在可以花费之前，有一个成熟倒计时。成熟后，入账栏会从 0.00 变为 50.00。区块要有效，就必须广播到网络并进入区块链，这也是未连接网络时生成功能不会运行的原因。如果你在未联网时生成了区块，网络不会知道它的存在，会继续构建不包含它的链，把它落在后面。等你的节点发现它没有被采用时，成熟倒计时就会变成“（未接受）”。把状态栏里的数减去 1，就是你的区块之后已接上的区块数。

Satoshi Nakamoto

比特币 v0.1 Alpha 发布说明

比特币是一种新型电子现金系统，使用点对点网络来防止双重支付。它完全去中心化，没有服务器或中央机构。

你可以在这里找到截图和下载链接： http://www.bitcoin.org

目前仅支持 Windows。包含开源 C++ 代码。

• 将文件解压到一个目录
• 运行 BITCOIN.EXE
• 它会自动连接其他节点

如果你能持续运行一个接受传入连接的节点，就能为网络提供很大帮助。你需要开放防火墙的 8333 端口，才能接收传入连接。

软件仍处于 alpha 实验阶段。虽然我已尽力加入可扩展性和版本管理机制，但无法保证将来在必要时不用重置整个系统的状态。

你可以让别人给你一些币，或打开 Options->Generate Coins，运行节点并生成区块。我把初始工作量证明难度设得低得离谱，所以刚开始的一小段时间里，普通 PC 只需几小时就能生成币。当竞争使自动调整机制提高难度时，就会困难得多。生成的币必须等待 120 个区块，成熟后才能花费。

有两种汇款方式。如果收款人在线，你可以输入他的 IP 地址，软件就会连接过去，获取一个新公钥，并发送附有备注的交易。如果收款人不在线，你可以向他的比特币地址付款，这个地址是他提供给你的公钥哈希。下次他连接网络，获取包含该交易的区块时，就会收到这笔交易。这种方式的缺点是不传送备注信息，而且如果一个地址被多次使用，可能损失一点隐私；但如果双方无法同时在线，或收款人不能接收传入连接，它就是一种有用的替代方式。

总流通量将为 21,000,000 枚币。它们会在网络节点创建区块时分配给节点，分配数量每 4 年减半。

最初 4 年：10,500,000 枚币接下来 4 年：5,250,000 枚币接下来 4 年：2,625,000 枚币接下来 4 年：1,312,500 枚币依此类推……

这些币发完后，系统可以在需要时支持手续费。这基于公开的市场竞争，而且很可能始终会有节点愿意免费处理交易。

Satoshi Nakamoto

比特币 v0.1.2 现已可供下载。

下载链接见 http://www.bitcoin.org。

我发现的问题都出在自动查找并连接其他节点的代码中，因为直到现在，我才有机会在实际网络环境中测试。真实互联网中，连接出问题的方式要多得多。

已修复的错误：

• 修复了导致新节点难以发现并连接其他节点的各种问题。
• 如果你在防火墙后面，程序只能接收一个连接，第二个连接会不断断开并重连。

这些问题正在扰乱网络，随着更多用户加入，情况会变得更糟，所以请务必升级。

Satoshi Nakamoto

谢谢你向我推荐 Wei Dai 的 b-money 论文及其他资料。

我刚刚发布了论文的开源实现，比特币 v0.1。详细信息、下载和截图都在 www.bitcoin.org

这个系统的主要想法，是生成一条基于哈希的工作量证明链，为多数共识提供不言自明的证明。用户通过向链贡献工作量证明来获得新币。

密码学邮件列表上曾讨论过这个设计。Hal Finney 作了一个很好的概述：

引用的来信Hal Finney来源 ↗

我可以提一点：在很多方面，比特币是两个独立的想法。一个是解决 James 在这里列出的这类问题，也就是建立一个全局一致、但去中心化的数据库；另一个是把它用于类似 Wei Dai 的 b-money（论文中引用了它）的系统，不过是基于交易和币，而非基于账户。正如 James 所强调的，解决全局性、大规模去中心化的数据库问题，可以说是更难的部分。我认为，将工作量证明用作实现这一目的的工具，是一个很值得进一步审视的新想法。

Satoshi

觉得你可能想知道：包含 EXE 和完整源代码的比特币 v0.1 版本已经放到 Sourceforge 上了；

http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar

www.bitcoin.org 上有发布说明和截图。

Satoshi

宣布比特币首次发布。这是一种新型电子现金系统，使用点对点网络来防止双重支付。它完全去中心化，没有服务器或中央机构。

截图请见 bitcoin.org。

下载链接： http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar

目前仅支持 Windows。包含开源 C++ 代码。

• 将文件解压到一个目录
• 运行 BITCOIN.EXE
• 它会自动连接其他节点

如果你能持续运行一个接受传入连接的节点，就能为网络提供很大帮助。你需要开放防火墙的 8333 端口，才能接收传入连接。

软件仍处于 alpha 实验阶段。虽然我已尽力加入可扩展性和版本管理机制，但无法保证将来在必要时不用重置整个系统的状态。

你可以让别人给你一些币，或打开 Options->Generate Coins，运行节点并生成区块。我把初始工作量证明难度设得低得离谱，所以刚开始的一小段时间里，普通 PC 只需几小时就能生成币。当竞争使自动调整机制提高难度时，就会困难得多。生成的币必须等待 120 个区块，成熟后才能花费。

有两种汇款方式。如果收款人在线，你可以输入他的 IP 地址，软件就会连接过去，获取一个新公钥，并发送附有备注的交易。如果收款人不在线，你可以向他的比特币地址付款，这个地址是他提供给你的公钥哈希。下次他连接网络，获取包含该交易的区块时，就会收到这笔交易。这种方式的缺点是不传送备注信息，而且如果一个地址被多次使用，可能损失一点隐私；但如果双方无法同时在线，或收款人不能接收传入连接，它就是一种有用的替代方式。

总流通量将为 21,000,000 枚币。它们会在网络节点创建区块时分配给节点，分配数量每 4 年减半。

最初 4 年：10,500,000 枚币接下来 4 年：5,250,000 枚币接下来 4 年：2,625,000 枚币接下来 4 年：1,312,500 枚币依此类推……

这些币发完后，系统可以在需要时支持手续费。这基于公开的市场竞争，而且很可能始终会有节点愿意免费处理交易。

Satoshi Nakamoto

那些 bug 追踪系统我一个都不了解。如果要用，就得先充分调研，再作选择。

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

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

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

那是在测试网上做的吗？

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

我会开始考虑怎么做。

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

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

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

我确认 ParseString 存在这个问题，并已把修复后的 util.cpp 上传到 SVN。

string::npos == -1

比较 unsigned int 的 -1（0xffffffff）与 long unsigned int 的 -1（0xffffffffffffffff）时，unsigned int 会被提升为 64 位，也就是 0x00000000ffffffff != 0xffffffffffffffff。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

这是我用 gdb 调试时得到的另一次测试运行的 debug.log。程序在“irc 8”这条调试信息之后开始吞噬内存，几秒内就崩溃，报错为“terminate called after throwing an instance of 'std::bad_alloc'”。

引用中本聪此前的文字中本聪来源 ↗

问题在 RecvUntil 里，但我还是看不出有什么不对。我唯一能想到的，是套接字正在接收大量字符。

试试这个 irc.cpp。debug.log 可能迅速增长，要随时准备强制终止程序。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

已附上 debug.log

引用中本聪此前的文字中本聪来源 ↗

这样范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它应该还没执行完 RecvUntil。粗看没有发现明显的问题。我想应该在 ConnectSocket 或 RecvUntil 其中之一。

用附上的 irc.cpp 和 net.cpp 试试，再把 debug.log 发给我。

或者你可以在 gdb 中运行，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或用 u 来单步越过，并从子程序中返回上层。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

不管有没有 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题解决了。

引用中本聪此前的文字中本聪来源 ↗

如果不执行 getinfo，还会发生吗？

你可以把下面列出的 CreateThreads 注释掉，然后逐个重新启用，直到问题再次出现。这样就能知道问题在哪个线程中。

net.cpp，在 // Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)

init.cpp： CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，不过 目前还没取得什么进展。它最后总是占用全部系统内存，然后崩溃。能否请你再发给我最新的 64 位 bitcoind 构建，好让我看看问题是否出在我自己编译的版本上？

其实，请改试这个，这样更正确：

void ParseString(const string& str, char c, vector<string>& v)
{
     string::size_type i1 = 0;
     string::size_type i2;
     loop
     {
         i2 = str.find(c, i1);
         if (i2 == str.npos)
         {
             v.push_back(str.substr(i1));
             return;
         }
         v.push_back(str.substr(i1, i2-i1));
         i1 = i2+1;
     }
}

引用中本聪此前的文字中本聪来源 ↗

问题在 util.c 的 ParseString 中。我猜是“unsigned int”类型与 str.npos 的类型不兼容，后者是 size_type。

试着把两个“unsigned int”改成“size_type”。

旧代码： void ParseString(const string& str, char c, vector<string>& v) { unsigned int i1 = 0; unsigned int i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); }

新代码： void ParseString(const string& str, char c, vector<string>& v) { size_type i1 = 0; size_type i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); }

引用 Martti Malmi 的文字Martti Malmi来源 ↗

这是我用 gdb 调试时得到的另一次测试运行的 debug.log。程序在“irc 8”这条调试信息之后开始吞噬内存，几秒内就崩溃，报错为“terminate called after throwing an instance of 'std::bad_alloc'”。

引用中本聪此前的文字中本聪来源 ↗

问题在 RecvUntil 里，但我还是看不出有什么不对。我唯一能想到的，是套接字正在接收大量字符。

试试这个 irc.cpp。debug.log 可能迅速增长，要随时准备强制终止程序。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

已附上 debug.log

引用中本聪此前的文字中本聪来源 ↗

这样范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它应该还没执行完 RecvUntil。粗看没有发现明显的问题。我想应该在 ConnectSocket 或 RecvUntil 其中之一。

用附上的 irc.cpp 和 net.cpp 试试，再把 debug.log 发给我。

或者你可以在 gdb 中运行，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或用 u 来单步越过，并从子程序中返回上层。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

不管有没有 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题解决了。

引用中本聪此前的文字中本聪来源 ↗

如果不执行 getinfo，还会发生吗？

你可以把下面列出的 CreateThreads 注释掉，然后逐个重新启用，直到问题再次出现。这样就能知道问题在哪个线程中。

net.cpp，在 // Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)

init.cpp： CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，不过 目前还没取得什么进展。它最后总是占用全部系统内存，然后崩溃。能否请你再发给我最新的 64 位 bitcoind 构建，好让我看看问题是否出在我自己编译的版本上？

问题在 RecvUntil 中，但我还是看不出它哪里有错。我唯一能想到的，是套接字可能在接收大量不断涌入的字符。

试试这个 irc.cpp。debug.log 可能会迅速增长，做好终止程序的准备。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

附上 debug.log

引用中本聪此前的文字中本聪来源 ↗

这样就把范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它应该还没执行完 RecvUntil。粗看没有发现明显问题。我想问题只能出在 ConnectSocket 或 RecvUntil 中。

试试附件中的 irc.cpp 和 net.cpp，然后把 debug.log 发给我。

或者你可以在 gdb 中运行它，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或者用 u 单步跳过，并退出子程序。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

不管是否执行 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题就解决了。

引用中本聪此前的文字中本聪来源 ↗

如果你不执行 getinfo，它还会这样吗？

你可以把下面列出的 CreateThread 调用注释掉，然后逐个重新启用，直到它再次出问题。这样我们就知道问题在哪个线程里了。

net.cpp 中，// Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)

init.cpp: CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃时的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，但 还没取得多少进展。它总会占满 系统的全部内存，最后崩溃。能否请你再次把最新的 64 位 bitcoind 构建发给我，让我看看问题是否出在自己编译的版本上？

这样就把范围缩小了很多。debug.log 中没有打印任何 IRC 活动，所以我猜它应该还没执行完 RecvUntil。粗看没有发现明显问题。我想问题只能出在 ConnectSocket 或 RecvUntil 中。

试试附件中的 irc.cpp 和 net.cpp，然后把 debug.log 发给我。

或者你可以在 gdb 中运行它，逐步执行 ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step 或者用 u 单步跳过，并退出子程序。

引用 Martti Malmi 的文字Martti Malmi来源 ↗

不管是否执行 getinfo，我都会遇到这个错误。注释掉 ThreadIRCSeed 后，问题就解决了。

引用中本聪此前的文字中本聪来源 ↗

如果你不执行 getinfo，它还会这样吗？

你可以把下面列出的 CreateThread 调用注释掉，然后逐个重新启用，直到它再次出问题。这样我们就知道问题在哪个线程里了。

net.cpp 中，// Start threads 下方 CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL)

init.cpp: CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃时的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，但还没取得多少进展。它总会占满系统的全部内存，最后崩溃。能否请你再次把最新的 64 位 bitcoind 构建发给我，让我看看问题是否出在自己编译的版本上？

如果你不执行 getinfo，它还会这样吗？

你可以把下面列出的 CreateThread 调用注释掉，然后逐个重新启用，直到它再次出问题。这样我们就知道问题在哪个线程里了。

net.cpp 中，// Start threads 下方

     CreateThread(ThreadIRCSeed, NULL)
     CreateThread(ThreadSocketHandler, NULL, true)
     CreateThread(ThreadOpenConnections, NULL)
     CreateThread(ThreadMessageHandler, NULL)

init.cpp:

     CreateThread(ThreadRPCServer, NULL);

引用 Martti Malmi 的文字Martti Malmi来源 ↗

发来了。我忘了说崩溃时的错误消息：

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

引用中本聪此前的文字中本聪来源 ↗

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，但还没取得多少进展。它总会占满系统的全部内存，最后崩溃。能否请你再次把最新的 64 位 bitcoind 构建发给我，让我看看问题是否出在自己编译的版本上？

能把 debug.log 发给我吗？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我试着用 ddd 调试器调试自己编译的 bitcoind，但还没取得多少进展。它总会占满系统的全部内存，最后崩溃。能否请你再次把最新的 64 位 bitcoind 构建发给我，让我看看是不是自己构建的问题？

引用 Martti Malmi 的文字Martti Malmi来源 ↗

我第一次在 Windows 上尝试时，首次下载等了几分钟才开始，虽然很快就建立了很多连接。我又试了两次，再没遇到同样的问题。我不知道这是否与你最近的更新有关。

大多数修复都在发送方这一侧，所以如果你当时正在下载，网络升级到 0.2。

首次下载花了多久？

谢谢。db::open/close 错误证实了这个规律。

更值得注意的是靠近结尾的僵尸套接字活动，套接字线程监测器被触发，却没让它恢复运行。当时机器断网了吗？test5 中的 MSG_DONTWAIT 解决了 Liberty 的僵尸问题。你当时运行的是哪个测试版本？（我应该把测试版本打印到日志里。）

引用 Martti Malmi 的文字Martti Malmi来源 ↗

这里是日志，如果它们还有用的话。

引用中本聪此前的文字中本聪来源 ↗

我想到一个变通办法，但要看是哪些文件出错。如果你的 db.log 已经积累了几次错误，能否发给我？（即使它相当简单、没什么看头。）列出的文件总是 blkindex.dat，还是也包括 addr.dat 或 wallet.dat？

总算有个容易的问题了。我看出，在首次下载这样的长时间操作中，有一种情况会导致它发生。TryLock 错误与数据库问题无关。修复会包含在 test8 中。

我现在已在 32 位 linux 上，通过持续不断的大量请求，成功重现了 3 次 db::open/close 异常。看来即使只是为了写盘而定期关闭 wallet.dat 数据库，也会出现 db::close 异常。我正在禁用 Linux 上的钱包写盘功能。在 Linux 上，直到准备退出，我们都不会关闭数据库句柄。目前禁用后还没有异常。

我也在实现有序的首次区块下载。不再直接一次请求所有区块，而是每次请求一批 500 个。这样就能在重试超时之前收到区块，除非确实没收到或速度太慢，否则不应再向其他节点请求。改动在被请求方，所以只有首次下载区块的来源节点使用了新版，才能看到这个功能。

发送 test8 之前，我会再多测一会儿。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我用一个全新数据目录启动了 test7。区块下载开始得快多了。只花了大约 15 秒，之前 Linux 构建要等几分钟。下载区块期间崩溃了一次，终端显示以下消息。

../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap

我附上了日志文件，不过重启 bitcoin 前忘了备份，所以不确定崩溃发生在日志中的哪一处。

幸好还没遇到段错误。之前几个构建中，段错误的发生频率波动相当大，所以我会继续运行，遇到问题再告诉你。

引用中本聪此前的文字中本聪来源 ↗

test 7：

运行之前备份数据目录，以防万一。

这是针对 Db::open/Db::close“Bad file descriptor”异常的变通办法。也可能会加快首次区块下载。办法是打开数据库句柄，然后在程序运行期间一直保持打开，其实这本来就是更常见的做法。如果不再一直关闭又打开，错误应该就没有机会发生。

唯一例外是 wallet.dat，我仍然会在写入完成后关闭它，这样才能把事务日志写入 dat 文件，让 dat 文件可以独立使用。这样，如果有人在比特币运行时备份，就会得到一份不需要数据库事务日志、本身就有效的 wallet.dat。

这次重新组织了数据库处理方式，所以可能会发现一些新的死锁。通常，如果发生死锁，界面会停止重绘，或者虽然仍显示“正在生成”，却不再使用 CPU。

linux-0.1.6-test5 解决了 Liberty 的僵尸套接字问题。MSG_DONTWAIT 修复了根本原因，不需要终止并重启线程。套接字原本已经标记为非阻塞，所以我不明白为什么。也许它忘了。我想，如果套接字失败，操作系统将其关闭，就没有东西能记住它曾经是非阻塞的；但访问已关闭的句柄，应该立即返回错误。Windows 上没有 MSG_DONTWAIT，唯一办法是把套接字标记为非阻塞，所以如果有人在 Wine 中运行 Windows 版，就只能依靠终止线程。

现在唯一的问题，是他遇到的数据库异常。

EXCEPTION: 11DbException
Db::open: Bad file descriptor
bitcoin in ThreadMessageHandler()
************************
EXCEPTION: 11DbException
Db::close: Bad file descriptor
bitcoin in ThreadMessageHandler()

我原以为这些是 Wine 的问题，但他在 Linux 上也同样遇到了。他尝试把 datadir 移到另一块硬盘上，没有帮助。我从未遇到过。我运行着压力测试，持续产生大量活动和数据库访问，也从未出现。

他用 64 位 Ubuntu，我用 32 位，所以我猜区别就在这里。你的 Linux 机器是 64 位还是 32 位？你有没有遇到过数据库异常？（也看看 db.log。）现在 test5 已经解决僵尸问题，你能开始在 Linux 机器上运行它吗？我们需要第三份结果，更好地了解正在面对什么问题。数据库异常没有被捕获，所以如果遇到，程序就会停止。

顺便说一下，Zetaboards 非要显示“会员编号”，所以你最好早点注册，抢个好账号号码。

12,033,918 linux-0.1.6-test5.tar.bz2

test 5：

我在 send 和 recv 调用中加了 MSG_DONTWAIT，以防它们忘了套接字是非阻塞的。如果还不行，现在还有一个兜底办法：用另一个线程监控 send/recv 线程，若它停止运行，就终止并重启它。程序会在 debug.log 中打印“*** Restarting ThreadSocketHandler ***”，状态栏也会显示一段时间的错误消息。

在终止之前，它会先尝试关闭卡住的套接字。如果成功，就不必采取终止线程这一步了。

我做了一次测试，终止线程大约 1000 次，没有出问题，所以应该安全。linux 上用于终止的是 pthread_cancel，它会让执行进入 C++ 的异常处理程序。

我们之前使用的线程调用没有终止功能，所以我在 util.h 中创建了自己的封装，在 windows 上使用 CreateThread，在 linux 上使用 pthread_create，而不是： _beginthread 仅适用于 windows，而且没有终止功能 boost::thread 很吸引人，但没有终止功能 wxThread 要求你为每个可能调用的函数创建一个类（真糟糕）

文件附在下一封邮件中。

已附上文件 linux-0.1.6-test3.tar.bz2

linux-0.1.6-test3.tar.bz2 12,143,473 字节

现在（04:50 GMT），我的节点正在连接你的节点，每次都得到僵尸连接。套接字没有返回错误，只是悄无声息地变成僵尸状态。如果你现在运行的是 linux 构建，就很值得看看你那边的日志写了什么。

test3：

我增加了专门检测僵尸套接字的代码。它会检测套接字是否在连接后的 60 秒内没有发送或接收任何数据，也会检测是否有数据排队等待发送、却已有 3 分钟没发出。

我想自己可能在 test2 中拖慢了重连速度。在 test3 中，我会让它更积极地快速重连。

我增加了检查，追踪其他节点是否收到了你生成的区块。如果没有任何节点收到，就会在描述中警告：“已生成——警告：没有任何其他节点收到这个区块，它很可能不会被接受！”

如果你创建的区块或交易没有传到任何其他节点，状态可能会变成“#/离线？”。

有了这些，一旦出问题，应该就能立即察觉。希望它能断开所有僵尸套接字。之后能否建立一些正常连接，还是套接字系统已经彻底失灵、一直停留在 0 个连接，我就不知道了。

如果这样还不行，我想我会看看 BitTorrent 等其他点对点应用的源代码，看看它们怎么处理这些问题。也许有某个神奇的标志或操作步骤，能把套接字系统重新救活。

文件 linux-0.1.6-test3.tar.bz2 会附在下一封消息中。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我的网络连接直接接到电脑。我的互联网服务提供商要求运行 VPN 才能连接互联网。我还有第二块网卡，把互联网连接共享给其他设备。我使用电脑时的 IP 地址就是真实 IP 地址，但通过第二块网卡连接的设备使用 NAT。通过虚拟机连接时，也使用 NAT。这些都只需要很少的配置。 Ubuntu 的 NetworkManager 提供通过第二块网卡共享互联网连接的选项，VirtualBox 也提供使用 NAT 的选项。

我又丢了几批比特币，所以这个问题还没修好。现在大致知道怎么回事了，倒是稍微能忍受一些。我想，目前只要看到一批比特币开始成熟，就重启 bitcoin。我可能会在 Linux 和 Wine 之间来回切换一阵，不过肯定会测试每一个发布的新版本。目前我仍然在运行 Linux 构建。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

谢谢。日志没有停在什么特殊操作上，只是简单的消息传递。很可能与界面有关。最初的大多数错误都在界面上。

你的防火墙是什么品牌／型号？BitTorrent 有可能超出某些型号能处理的连接数量。大多数设备性能不足，负载高时不太稳定。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我一直能正常收到你的附件。我只是想替 Martti 省掉那个大附件。

我无法重现这个错误。我不知道是粘贴、区块下载完成，两者结合，还是完全别的什么引发了故障。

...

但在它们开始下载后，我看了看 BitTorrent 客户端，果然，我忘了一个 torrent 任务，上传量很高，达到了我设定的上限。

已附上 linux-0.1.6-test2.tar.bz2

我发现有几处可能让套接字出错后却没有断开连接，已经修复了。如果你的连接再次失效，现在应该会断开并重新连接。我还实现了一个无活动超时机制作为后备措施。

这也包含了对初始区块下载缓慢问题的部分修复。

你应该带上“-debug”开关运行，以获得我添加的一些额外 debug.log 信息，如果再出问题，这些信息会有帮助。

linux-0.1.6-test2.tar.bz2 12,134,012 字节
下载：
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）。这个数字对区块的意义，不如对交易那么大。

我觉得不把自己生成的区块算作确认，会是一种改进。缺点是不同节点显示的状态数字会不一致。状态数字也不再与区块成熟倒计时相对应。较轻量的选择是：只有当所有确认都来自自己时，才作特殊处理。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我刚丢了 6 组正在成熟的币！我原本有 10 组比特币正在成熟。最后一组大约在 0:22 生成。在 bitcoin 卡住之前，它到了 2/unconfirmed。到了 10:10， 0:22 生成的那组比特币仍然只有 2/unconfirmed。因为你告诉我不会丢币，我就关闭并重新启动了 bitcoin。好的一面是，它关闭和启动都很顺利。但不幸的是，区块更新后，我丢了 6 组比特币。四组还未确认，但两组已经确认。现在它们没有留下任何痕迹。也许既然你已经提供了“Show Generated Coins”选项，就可以把生成失败的比特币重新显示出来。我只是不喜欢这些比特币就这样凭空消失。我目前仍在运行 Linux 构建，但过去 24 小时生成的 10 组比特币中有 6 组就这样消失，让 Wine 版本突然显得有吸引力得多。我附上了 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 数字只是用来观察结果。 在这段时间里， 你的节点不会做任何事情来促进 它被接受。

谢谢，我看出发生什么了。因为第一个节点很慢，程序最后向其他所有人都请求区块，结果只是把一切都拖慢了。我能修复，只是需要花点时间想想正确的办法。

有未确认内容时关闭程序没有风险。当你创建交易或新区块时，程序会立即将它广播到网络。之后不断增加的 #/已确认 数字只是在监测结果。在这段时间里，你的节点不会做任何促进接受的事情。

现在想起来，关闭比特币时，主窗口会立即关闭，但程序还会在后台继续运行，完成有序的数据库写盘和关闭。在我实现这一点之前，总有个卡死、无响应的窗口挂在那里，很烦人。在后台完成有序关闭之前，端口会一直被占用，这是一项重要保护，确保在关闭过程完成前，另一个实例不能访问数据库。我还没见过关闭过程超过几秒的情况。

在 Wine 中，Windows 版本无法使用 SO_REUSEADDR，所以端口关闭后还会增加 60 秒的 TIME_WAIT（在我的系统上是这样）。

如果需要在两个实例之间转账，可以发送到另一个实例的比特币地址。接收的实例当时不必在线。

使用不同数据目录的命令行是 bitcoin -datadir=<directory>

例如，在 Linux 上，默认目录是（不要用 ~） bitcoin -datadir=/home/yourusername/.bitcoin

通常应该完全不需要使用这个开关。它仍然不会让你同时运行两个实例。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

引用中本聪此前的文字中本聪来源 ↗

大约花了多久才开始？可能只是你碰巧请求的那个节点很慢。开始得慢，与下载速度慢的情况一致。

我想看看你现在的 debug.log 文件，试着弄清楚发生了什么。可能只是对方的连接非常慢，也可能哪里出错，失败后又重试。耗时太久可能会让其他用户困惑。

Martti，你运行时，花了多久才开始下载区块，下载速度有多快？

它已经使用 SO_REUSEADDR，所以端口关闭后处于 TIME_WAIT 状态时，仍能绑定到该端口。只有程序真的已经在运行，才应该绑定失败。不能让两个比特币实例同时在一台机器上运行，这很重要，因为它们会同时修改数据库。 一台机器上从来都不需要运行两个实例，因为生成功能现在会自动使用多个处理器。

我不确定那些库错误是什么，我会搜索一下。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

好，区块数现在开始增加了。它开始增加所需的时间肯定比 Windows 版更长。而且我觉得，增长速度可能也比 Windows 版慢。你发给我的 Linux 构建是不是开启了调试？区块数大约每秒增加 15 个（看着时钟目测的估计）。我没计时 Windows 版的增长速度，但感觉要快得多。

大约半小时后，它才开始快速增加。有意思的是，CPU 使用率在开始稳定增加前升高，等开始稳定增加后又降低了。不过这一次，区块数在最初几分钟内就增加到了 2。我还没有生成任何比特币。我会耐着性子等生成一个比特币，但如果耐心耗尽时还没有生成，我就会回到 wine 版本。

已附上我现在的 debug.log。

我启动 bitcoin 而 bitcoin 端口不可用时，命令行会出现以下消息。bitcoin 端口可用时，就没有这些消息。如果默认端口已被占用， bitcoin 能否选择另一个端口？我的 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 时又发生了一次。

我还注意到，“关于”对话框的文字没有正确适配，而且不能调整大小。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

好了，区块数现在开始增加了。它开始增加前等待的时间，肯定比 Windows 版长。而且我觉得，增加速度可能也比 Windows 版慢。你发给我的 Linux 构建是不是启用了调试？区块数大约每秒增加 15 个（我看着时钟目测的）。我没测 Windows 版增加得有多快，但感觉快得多。

大约等了多久才开始？可能是你碰巧请求的那个节点很慢。开始下载前等待时间较长，与下载速度慢的情况一致。

我想看看你目前的 debug.log 文件，试着弄清楚发生了什么。可能只是对方连接特别慢，也可能哪里出了问题，失败后又重试。耗时太长可能让其他用户困惑。

Martti，你运行时，等了多久才开始下载区块，下载速度又有多快？

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我启动 Bitcoin 时，如果比特币端口不可用，命令行就会
出现以下消息。端口可用时，不会出现
这些消息。如果默认端口被占用，能否让
Bitcoin 选择另一个端口？我的
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

它已经使用 SO_REUSEADDR，所以端口关闭后处于 TIME_WAIT 状态时，也能绑定。只有程序确实已经运行，才应该绑定失败。不能在同一台机器上同时运行两份 Bitcoin，这很重要，因为它们会同时修改数据库。现在生成币已经会自动使用多个处理器，完全没有必要在一台机器上运行两份。

我不确定那些库错误是什么，我会搜索一下。

在 debug.log 中，它请求区块列表、收到区块列表，然后开始上传所请求区块的列表。它没有收到区块，但运行时间还不够长，我无法确定它是否已经有足够时间收到。其他情况看起来都正常。

你让它运行了多久？开始下载区块可能需要几分钟。尤其是如果你用有线电视调制解调器，上行带宽可能低得多，因此上传区块请求列表需要一些时间。

如果你再次运行后仍然不下载区块，请让它至少运行几个小时，然后把 debug.log 发给我。这样应该能给我的节点足够时间连接你，我就可以看看自己这边显示什么，再与你的 debug.log 对照。

关于关闭时最小化的选项，你说得对，没有理由不能单独设置。Martti 最初把它独立设置，是我改成了子选项，是我的错。我会改回来。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我就是这个意思。我运行程序时，状态栏显示的区块数完全没有增加。我附上了 debug.log。

在 Gnome 中测试托盘图标的一个好办法，是移除通知区域，再把它加回来。如果重新添加通知区域后图标仍然显示，就说明它工作正常。

我通常把应用程序设置为最小化时不进托盘，关闭时才进托盘。然后让应用保持最小化。这样我既不会意外关闭程序，又能方便地从托盘打开它。（我不在“任务栏”显示打开的窗口，而是放了一个图标，点击后把打开的窗口显示为子菜单项。）这样，如果托盘图标消失，我会进入设置，禁用再启用托盘图标设置，让它重新出现。目前 bitcoin 的设置做不到这一点，因为只有先勾选最小化到托盘，才能勾选关闭到托盘。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

如果你是说状态栏中的区块计数没有逐渐增加到 26600 左右，那就是一个错误，你应该把 debug.log 发给我。（它在 ~/.bitcoin/debug.log）

我们还没弄清，在 Linux 上怎样像 Windows 那样找到并调出已经运行的程序。根据你的描述，我至少应该把最小化到托盘选项的初始默认状态设为关闭。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我下载后运行起来了。它使用了不少 CPU，所以我想它工作正常。它没有下载之前生成的区块。这是错误还是新功能？

Gnome 的系统托盘不太可靠。有时一个图标会消失，让人无法再回到程序。我已经确认 bitcoin 也可能遇到这种情况。如果在 bitcoin 已经运行时再次启动它，只会调出已运行的 bitcoin 进程的 GUI，那就好了。

Linux 构建已经可以在网络上测试了，看起来很稳定。我在上一封邮件中附上了可执行文件，但如果邮件服务器没有放行（文件有 12MB），可以在这里下载： http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html

已附上 bitcoin-linux-0.1.6-test1.tar.bz2

Liberty Standard 写道：

引用的来信Liberty Standard来源 ↗

你们 Windows 用户会遇到比特币偶尔崩溃吗？最近在 wine-1.0.1 中运行的比特币频繁崩溃。我只是想知道，这是 Wine 的问题，还是比特币的问题。

我还没收到任何 v0.1.5 崩溃报告。它在我的 Windows 上一直非常稳定。我想应该与 Wine 有关。如果你在 Wine 中再次遇到崩溃，而且终端打印了任何内容，请发邮件给我，我也许能弄清发生了什么，或许可以想办法绕过。Martti 和我一直在开发一个即将发布的新版本，如果能把 Wine 的修复一起加进去就好了。

引用的来信Liberty Standard来源 ↗

我启动比特币时，终端会打印以下四行。 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub

这些看起来不用担心。可能是 Wine 尚未实现的函数，用无害的空桩代替了。

引用的来信Liberty Standard来源 ↗

我以前不是从终端启动比特币的，所以不知道崩溃时会打印什么，不过下次崩溃我会把结果发过来。

比特币首次下载之前完成的区块时， debug.log 文件会增长到 17.4 MB，然后停止增长。我想随着更多比特币完成，它会继续增长。

如果不想占用磁盘空间，可以偶尔删除 debug.log。里面只是有助于调试的状态消息。

bitcoin.sourceforge.net 现在看起来正常。可能是 sourceforge 当时正在维护。

Satoshi

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

你们这些 Windows 用户会偶尔遇到 Bitcoin 崩溃吗？最近 Bitcoin 在 wine-1.0.1 中运行时经常崩溃。我只是想知道，这是 Wine 的问题还是 Bitcoin 的问题。

我还没有收到任何 v0.1.5 崩溃的报告。对我来说，它在 Windows 上一直非常稳定。我想一定与 Wine 有关。如果你再次在 Wine 中遇到崩溃，而且终端打印了什么，请发邮件给我，我也许能弄清发生了什么，或许可以想办法绕过。Martti 和我一直在开发一个即将发布的新版本，如果能把 Wine 相关的修复也加进去就好了。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

我启动 Bitcoin 时，终端打印了下面四行。 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub

这些看起来没什么需要担心的。可能是 Wine 没有实现的一些函数，被无害的空实现代替了。

引用 New Liberty Standard 的文字New Liberty Standard来源 ↗

之前我不是从终端启动 Bitcoin 的，所以不知道崩溃时会打印什么，但下次崩溃时，我会回复结果。

Bitcoin 首次下载之前已完成的区块时， debug.log 文件增长到 17.4 MB，然后就停止增长。我想随着更多比特币完成，它还会继续增长。

如果不想占用磁盘空间，你可以偶尔删除 debug.log。里面只是帮助调试的状态消息。

bitcoin.sourceforge.net 现在看起来正常了。也许 sourceforge 当时在做维护。

Satoshi

自动附加的广告与页脚邮件列表系统来源 ↗

---

来和我们一起开发吧！在加利福尼亚州旧金山举行的 BlackBerry(R) 开发者大会是你今年唯一需要参加的开发者活动。迅速提升你的开发技能，将 BlackBerry 移动应用推向市场，并保持领先。欢迎在 2009 年 11 月 9 - 12 日加入我们。立即注册！ http://p.sf.net/sfu/devconference

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

发件人：Nicholas Bohm 2009-01-25 10:17

引用的来信Nicholas Bohm来源 ↗

我在运行 bitcoin 时遇到了几个问题：适合在这个邮件列表报告吗（有大约 70kb 的附件）？

你遇到了什么问题？

如果你把 debug.log 文件直接发给我（最好不要向邮件列表发送附件），我可以看看发生了什么。

Satoshi Nakamoto bitcoin-help at vistomail dot com

引用的来信Dustin D. Trammell来源 ↗

它实际上把哈希区块发布到一个叫“proof-hashes”的 Google 群组，所以效果与发布到 Usenet 类似。

http://groups.google.com/group/proof-hashes

这个群组由我管理，唯一用途就是归档工作量证明哈希，所以如果你愿意，欢迎加入一个账号，让你的系统也往那里发布。

太好了，我之前曾在 Usenet 上寻找这样的群组，想看看真有需要时能用哪个，但没有找到合适的。我相信往 Google 群组发帖要容易得多。

在某些情况下，Usenet 或 Google 群组可以用作补充防御。比特币在初期最脆弱，因为那时全网 CPU 总算力较小。不过，规模小时，攻击它的动机也较弱，这抵消了一部分风险。希望只需不断发展、度过那个阶段，这个简单办法就能奏效。如果不行，真到了那一步，Google 群组也有一些可以帮上忙的方式。

引用的来信Dustin D. Trammell来源 ↗

电子货币和密码学是我非常感兴趣的两个领域，所以你也能想到，我在密码学邮件列表上看到这个项目时，立刻就被吸引了。如果需要反馈或测试新功能，随时找我，我很乐意帮忙。

我们的兴趣确实很相近！

你知道，我觉得 90 年代对这个领域感兴趣的人要多得多，但经过十多年基于可信第三方的系统（Digicash 等）不断失败，他们认为这已经没有希望了。我希望他们能分清区别：据我所知，这是我们第一次尝试一个不依赖信任的系统。

引用的来信Dustin D. Trammell来源 ↗

等这些币成熟后，会生成一笔新的“入账”交易，还是更新现有生成交易行中的入账字段？

现有的交易行会发生变化。

引用的来信Dustin D. Trammell来源 ↗

打开 0.1.3 版后，我的四条交易记录仍然都显示“未确认”，但描述现在变成了“已生成（未接受）”。这是否意味着某个其他节点先延长了链，而我的币生成在一条被废弃的分支上？如果是，为什么之前运行的软件没有立即发现这一点，并开始在获胜的分支上生成币？是 0.1.0 的错误吗？

你说得对，很抱歉。这正是 0.1.3 修复的那个错误。通信线程会被阻塞，所以虽然能建立连接，但过一阵子这些连接就不再传输信息。当你找到区块时，无法将它广播到网络，所以它没有进入链中。同时你也收不到任何信息，因而不知道网络已经撇下你继续向前，直到你重启程序。

这个错误也导致 bitcoin.exe 无法退出。通信线程被阻塞，无法退出。比特币关闭时会很谨慎，以防刚好正在处理一笔重要交易，但实际上，强制终止它完全安全。

这些在 0.1.3 中都修好了。如果你把 IP 发给我，我会给你发送一些币。

引用的来信Dustin D. Trammell来源 ↗

我还有一个问题……是什么防止 CPU 算力最强的单个节点生成并保留大多数 BitCoins？如果每个节点都独立于其他节点工作，而其中一个比其他节点强大得多，难道这个节点不就很可能比其他节点更早得到正确结果吗？算力不足的节点可能偶尔会碰上好运，但如果它们拥有明显的算力优势，我会认为大多数 BitCoins 都会由最强的节点生成。

这不像赛车，不是有一辆车速度快一倍，就总能赢。这是一次耗时不到一微秒的 SHA-256 运算，每次尝试都有独立的成功概率。每台电脑找到哈希碰撞的概率，与它的 CPU 算力成线性比例。一台速度只有一半的电脑，会获得一半数量的币。

引用的来信Dustin D. Trammell来源 ↗

我会观察这次运行的情况，看看怎么样……

告诉我运行情况如何。如果遇到任何问题，把 debug.log 文件发给我。我常常只凭它就能看出哪里出了问题。

Satoshi

你能把 0.1.3 崩溃时的 debug.log 发给我吗？通常只看这个文件，我就能得到很多信息。

我很快就把调试版发给你。

引用 Hal 的来信Hal Finney来源 ↗

很遗憾，看起来 0.1.3 在夜里崩溃了。下次我会试着运行调试版。今天我需要工作，会频繁开关这台电脑，所以白天大部分时间都没法让它运行。今晚我会试着花点时间看看。

Hal

好的，也就是说没有崩溃、异常窗口之类的情况。那我只需要 debug.log 就够了。

看起来出现了“select failed: 10038”错误（套接字的 select 函数失败了），此后网络通信就没动静了，只有 IRC 还在工作。我以前从没遇到过 select 失败。看起来套接字的部分功能不知为什么出了故障。至少现在我知道问题出在哪里了。

你应该重启它。它现在没有在做任何事。我不知道重启后会不会再次出现“select failed”错误，还是能正常运行一阵子。

如果想不出别的办法，遇到这种套接字出故障的情况，我总可以先关闭它们，再重新启动。我相信，凡是写过浏览器或点对点应用等网络程序的人，都不得不费力应对网络带来的各种麻烦。网络环境可真够混乱难缠的。

关闭程序后 bitcoin.exe 仍在运行，这是个已知问题。为格外稳妥起见，它会谨慎地关闭各个部分，以防当时有重要交易正在进行；但如果它没有自行退出，直接结束进程也完全没问题，而且是安全的。我还得找出究竟是哪里卡住了。也许我会让它超时后自行终止。

谢谢！

引用 Hal Finney 的来信Hal Finney来源 ↗

你好，Satoshi——随信附上 debug.log。今天下午启动 0.1.2 时，我先退出了正在运行的旧版本，可 0.1.2 还是启动不了。我看了调试日志，里面写着“Existing instance found”。打开任务管理器后，我发现有两个名叫 bitcoin.exe 的进程在运行。我把它们都结束掉，再启动新版本，它似乎就能正常运行了。底部显示“3 connections”。我还没有试调试版本，因为不知道该查看什么。

Hal

能把你的 debug.log 发给我吗？

随信附上 gcc 调试版本。

gdb 比你想象的容易用，只需要 gdb.exe 这一个文件。先运行 gdb bitcoin.exe，然后输入“run”。如果程序崩溃，再输入“backtrace”来输出调用栈；它也可能会自动输出。（可惜，调用栈回溯并不总能追溯得足够远。）

这情况看起来不太妙。你升级到 0.1.2 后，节点回复了一两条消息，随后就不再回复了。它仍在接受连接，在 IRC 上看起来也还活跃。如果 ThreadSocketHandler 或 ThreadMessageHandler 卡住、崩溃或阻塞，就可能出现这种情况。通常发生异常或其他问题时，只会停止受影响的线程，其余部分仍会继续运行。

随信附上 msvc 调试版本，需要时可以使用。

Satoshi

我曾短暂地复现这个问题，并把范围缩小到下面代码中的“mapAddresses.count”。这段代码确实是最后才加进去的，基本上只在 MSVC 编译的版本中测试过。它不是必需的；在弄清楚原因之前，我倾向于关闭优化，并删掉这段代码。

随信附上一个调试版 exe，你可以试试。这个版本删掉了那行代码，并关闭了优化。目前我又没法复现这个问题了。

irc.cpp:

if (pszName[0] == 'u') 
{ 
    CAddress addr; 
    if (DecodeAddress(pszName, addr)) 
    { 
        CAddrDB addrdb; 
        if (AddAddress(addrdb, addr)) 
            printf("new  "); 
        else 
        { 
            // make it try connecting sooner 
            CRITICAL_BLOCK(cs_mapAddresses) 
                if (mapAddresses.count(addr.GetKey())) 
                    mapAddresses[addr.GetKey()].nLastFailed = 0; 
        } 
        addr.print(); 
    } 
    else 
    { 
        printf("decode failed\n"); 
    } 
}

引用 Hal Finney 的来信Hal Finney来源 ↗

是的，其实带 MSVC 调试符号的版本更好，我用的就是它。

我发现，从 cygwin shell 启动这个版本时，它不会崩溃。但如果在 Windows 中双击文件启动，它就会像上一个版本一样崩溃。不过，我很确定，上一个版本即使从 cygwin 启动也会崩溃。

我得出门了，不过会让这个版本继续运行一阵子。

Hal

通常我会保留调试符号，但它们会让 EXE 文件从 6.5MB 增大到 50MB，所以实在不适合把它们保留下来。我想这个决定做错了，至少对这么早期的版本来说是这样。发生崩溃让我有些意外：我做了大量测试，已经有一阵子没有遇到直接抛出异常的情况了。仔细想想，debug.log 的末尾甚至没有打印异常信息。我一直在 XP SP2 上测试，也许与 SP3 有关。

随信附上带有调试符号的 bitcoin.exe。（这是供 gdb 使用的 gcc 调试符号；如果你用的是 MSVC，我可以发一个带调试符号的 MSVC 编译版本给你。）

谢谢你的帮助！

引用 Hal Finney 的来信Hal Finney来源 ↗

你好，Satoshi——我试着运行 0.1.0 软件包里的 bitcoin.exe，结果崩溃了。我运行的是已经更新到最新状态的 XP SP3。随信附上 debug.log 的输出。另外还有一个 db.log 文件，不过是空的。

崩溃时我可以启动调试器，但没有调试符号。异常发生在地址 00930AF7。显示的调用栈是 508936 调用了 942316。

有时间的话，我会试着自己编译，不过看起来要花些时间才能把所有依赖都准备好。

Hal

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

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

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

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

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