隐私与匿名

0.2 版会加入代理设置，可以通过 TOR 连接。我已经仔细排查过，确保在代理模式下它不使用 DNS，也不会做任何泄露你 IP 的事情。

其他参与者原话bitcoinbitcoin

网络上的节点能分辨比特币从哪个比特币地址发出、发到哪个比特币地址吗？区块里是否保存着比特币转来转去的历史？

比特币会从一个比特币地址转到另一个地址。比特币地址本质上是一串随机数，本身不包含任何身份信息。

按 IP 地址发送时，交易仍会写入一个比特币地址。IP 地址只是用来连接收款方的计算机，向其索取一个新的比特币地址、把交易直接交给对方并获得确认。

区块保存着比特币被转往哪些比特币地址的历史。如果使用这些比特币地址的人身份不明、且每个地址只用一次，那么这些信息所能表明的，只是：某个身份不明的人，给另一个人转了某个数额。

要保持匿名或只使用化名，关键是不要把任何身份信息与你使用的比特币地址联系起来。如果你在网上公开自己的比特币地址，这个地址及其所有交易就会与你发帖时使用的名字关联起来。如果这个名字只是一个从未与真实身份关联的网名，你仍然处于化名状态。

如果想获得更高的隐私，最好每个比特币地址只用一次。你随时可以在 Options->Change Your Address 里更换地址。按 IP 地址转账时，每次都会自动使用新的比特币地址。

其他参与者原话bitcoinbitcoin

节点能判断哪些比特币地址属于哪些 IP 地址吗？

不能。

其他参与者原话bitcoinbitcoin

bitcoin 首次启动时，有没有命令行选项可以启用 sock 代理？

在下一个版本（0.2 版）中，从第一次运行就走代理的命令行是：

bitcoin -proxy=127.0.0.1:9050

TOR 的问题在于，Bitcoin 用来初始发现其他节点的 IRC 服务器封禁 TOR 出口节点——所有 IRC 服务器都这么干。如果你之前已经连上过一次，那已经有了种子节点；但第一次运行时，你需要提供一个节点地址，像这样：

bitcoin -proxy=127.0.0.1:9050 -addnode=

如果有谁运行着静态 IP、可接受入站连接的节点，愿意把自己的 IP 贴出来供 -addnode 使用，那就太好了。

其他参与者原话bitcoinbitcoin

如果向一个通过 NAT（网络地址转换）接入了多个客户端的 IP 地址发送比特币，会发生什么？

你在 NAT 上把 8333 端口转发给哪台机器，哪台机器就会收到。如果你的路由器转发时能改端口号，你可以让不止一个客户端收到。比如把 8334 转发到某台计算机的 8333 端口，发送方就可以发到 "x.x.x.x:8334"

如果你的 NAT 不能转换端口号，目前没有修改 bitcoin 入站绑定端口的命令行选项，但我会研究一下。

有用的建议，谢谢。

其他参与者原话madhatterDecember 09, 2009原帖 ↗

• bitcoin 软件与对端建立连接时（客户端 TCP 套接字），应改由客户端发送握手字符串。现在是服务端（服务端 TCP 套接字）先发握手。我的理由当然是为了匿名。ISP 对客户端做端口扫描、探测到他们在运行这个程序，实在是太容易了。

这确是个好主意。接受连接的一方，只需忍住不发任何东西，直到收到有效的握手。端口扫描所能碰到的，只是一条不会自报家门的死连接。

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

• 在握手阶段使用某种加密（和上面的建议相配），在 DPI（深度包检测）面前混淆软件的身份。我真正惦记的是中国、伊朗这类不自由（指自由意义上的）国家的人们。

我想过最终给所有连接加上 SSL。我猜在 DPI 面前，不上 SSL 的一切手段都是白搭。也许更好更快的办法，是走 TOR 连接，0.2 就可以做到。

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

• 需要某种 API，让这套系统能与网站集成、提供即时开通的服务。一个简单的 https 回执机制就能创造奇迹。让客户端把每笔收到的付款连同全部相关信息 POST 到一个 https url，并提供状态更新。最好还有一个出账支付机制，这样可以自动化地付款（以及批量付款）。状态可以通过 https 回执接口返回。

这是 0.2 之后日程表上的头等大事之一。

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

• 固定端口/随机端口。加一个设置项，随机分配运行端口（同时也能为防火墙极严的环境固定端口）。

是啊，如果端口永远是同一个，其他隐身手段，也就没什么意义了。

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

• UPnP 支持。让客户端自动在上级路由器上创建端口转发。默认启用，可在选项菜单关闭。

我很期待试 UPnP。大多数 P2P 客户端一般默认都启用 UPnP 吗？

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

• 支持为 *NIX 系统编译无头（仅控制台）版本。还能直接作为网络服务运行，不妨留一个可 telnet 的控制端口（甚至用 unix 套接字也行）。

我还在思量管理接口怎样设计为最好。也许用命令行命令与后台守护进程通信，查询收到的交易、发起转账，这样对自动化更为友好。或者在某些非 80 端口上开一个 http 接口，用浏览器管理，如何？

这事我想了一阵了。我想先给 .onion 地址加上后端支持和连接能力，然后从这里继续。

现在没什么人用 .onion 地址，因为用户得走一堆步骤才能建一个：配置 TOR 生成 .onion 地址，重启 TOR，再把生成的地址配置进去。也许这是有意的，好让 TOR 无法以足够自动化的方式集成进文件分享程序。

用代理端口 9050 时，它只会尝试连接 IRC 一次就放弃，因为它知道 IRC 服务器封禁所有 TOR 出口节点，多半永远连不上。如果用别的端口，它会以为那是个普通的老式代理，会以越来越长的间隔不断重试 IRC。不要用 Polipo 或 Privoxy，那些是 http 过滤器和缓存，一旦改动内容就会破坏 Bitcoin 的消息。Bitcoin 可能正试图通过重连来克服这个问题。你应该用 9050 端口。

如 riX 所说，"is giving Tor only an IP address. Apps that do DNS..." 这类警告不用理会。Bitcoin 在代理模式下完全不用 DNS。

由于 Bitcoin 经 Tor 无法连上 IRC，它不知道当前哪些节点在线，只能尝试所有最近见过的节点。它尽量节省连接尝试，但人们也希望它启动时快速连接、断线后快速重连。它用了一个算法：一个 IP 距上次连接成功越久，尝试频率越低。比如对一个 24 小时前见过的节点，它会等 5 小时再试。一旦有至少 2 条连接，超过一周没见过的就不再尝试；有 5 条连接时，超过 24 小时不再尝试。

向比特币地址转账时，你不会直接连接收款方，而是像转发其他交易一样，把交易发送到网络。别人无法分辨一笔交易是由你发起的，还是你从其他节点收到后继续广播的。不过目前网络还很小，仍可能有人通过排除法推断出来。等网络扩大后，情况会好很多。

如果按 IP 地址发送，收款方会看到你，因为你需要直接连接对方的 IP。可以用 TOR 隐藏这层信息。

如果你不想让别人知道自己正在使用 Bitcoin，也可以使用 TOR。

Bitcoin 还很新，也没有经过独立的安全分析。如果你很重视隐私，使用 TOR 是一项值得采取的预防措施。

没错，通过 Tor 按 IP 发送，只是用一个问题换另一个问题。Tor 出口节点能看见你消息的明文，还可能对你发起中间人攻击。

那么最好只发送到比特币地址。发往比特币地址的付款，作为正常网络流量的一部分在网络上广播。与网络的一切通信，都属公开信息的广播。

其他参与者原话XunieMay 14, 2010原帖 ↗

我建议在用户使用代理时禁用 IP 交易！

以求稳妥。

好主意。至少也该弹一个警告对话框，说明它将连接该 IP 并以明文发送信息，给用户取消的机会。

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

我们能不能强制用户用新地址收款？每次收到付款，就在地址栏显示另一个比特币地址。（只针对经比特币地址的交易，当然不包括 IP——那本来就没用，对吧？）

实际密钥仍然保留，确保用户仍能收到发往同一地址的付款。

这在我的清单上。我很快会让"你的比特币地址："窗口在显示的地址一旦收到任何东西时自动更换。

我也向 web 应用的实现者推荐这个做法。我刚贴了一些示例代码，展示一种建议的实现方式。

0.2.4 之后的 SVN 版本在地址栏旁边已经有 "New..." 按钮了，鼓励大家手动更换。

@theymos：退一万步说，将来我们还可以退回那个解决方案。

这是个非常有趣的话题。如果找到了解法，就能实现一种好得多、更容易、更方便的 Bitcoin。

最初，一枚币可以只是一串签名。有了时间戳服务，旧的可以在回溯扇出过大之前逐步丢弃，或者比特币可以单独或按面额保存。需要检查不存在双重支出，才是需要全网知晓所有交易的原因。

挑战在于：如何证明不存在其他花费？看来节点必须知道所有交易才能验证这一点。如果它只知道 in/outpoint 的哈希，它就无法检查签名以确认某个 outpoint 是否被花过。对此你有什么想法？

很难想出如何在这种情况下应用零知识证明。

我们要证明的是某种东西*不存在*，而这似乎要求知道全部、并检查那个东西不在其中。

还在琢磨这个想法……

网络唯一要做的，是判断对某个 outpoint 的花费是不是第一次。

如果我们愿意让客户端为自己的钱保存历史，那么有些信息也许不必由网络存储，比如：

• 金额
• 一笔交易中 inpoint 与 outpoint 的关联

网络跟踪一堆相互独立的 outpoint。它不知道它们属于哪些交易、金额多少。客户端可以查询一个 outpoint 是否已被花掉，并提交一个令人满意的 inpoint 来标记它已花费。网络保存该 outpoint 和证明其已花费的第一个有效 inpoint。inpoint 对其关联的下一个 outpoint 的哈希和盐做签名，这样，如果你知道盐，就能私下出示「该签名签署了某个特定 next outpoint」；但公开地，网络不知道下一个 outpoint 是什么。

我认为客户端将不得不保存回溯到最初挖矿的全部历史。发付款的人得向收款人发送数据，同时还要与网络通信以标记 outpoint 已花、并检查这次花费是否为首次。也许数据传输可以用 e-mail 附件完成。

客户端必须保存全部历史这一点削弱了隐私收益。经手大量钱的人仍然会看到大量交易历史。由于历史会回溯式地扇出，他们最后可能看到大部分历史。面额可以做得足够细以限制扇出，但经手大量钱的商家仍可能看到很多历史。

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

我起初也这么想。但后来我说服了自己，并非这样。

你这里说的是在讲现有的 Bitcoin 系统吗？

我说的是我描述的那个假想系统：如果网络不知道交易的金额和世系，它就无法验证并为其背书，那么客户端就得把历史一路保存到底。

如果一个客户端直到最近才加入，让它确信一笔交易拥有有效过去的办法有两条：

1) 给它看回溯到最初挖矿的完整历史。

2) 给它看回溯到一个足够深的区块的历史，然后相信：这么多节点都说此前的历史是正确的，那它就应该是正确的。

但如果网络不知道所有交易的金额和世系，它就做不了 2)，我认为。

我还没搞懂你的想法。它对公共网络隐藏了什么信息吗？优势在哪里？

如果至少 50% 的节点把交易校验到了可以丢弃旧交易的程度，那所有人都看到了一切，本可以留下记录。

公共节点能看到交易的金额吗？能看到金额来自哪笔先前的交易吗？如果能，那他们就什么都知道了。如果不能，他们就无法验证金额来自有效来源，你也就不能把他们生成的链当作交易的校验凭据。

它隐藏的是 bitcoin 地址吗？是这个吗？好，也许我现在明白了，如果是的话。

密码学也许提供了一种「密钥盲化」的办法。我做过一些调研，这方面的资料很冷门，但也许有些东西。「群签名」可能与此相关。

这个大方向上有一些东西：

http://www.users.zetnet.co.uk/hopwood/crypto/rh/

我们需要的是一种为一个公钥生成额外盲化变体的方法。盲化变体要具有与根公钥相同的性质，使得私钥可以为其中任何一个生成签名。其他人无法判断某个盲化密钥是否与根密钥相关，也无法判断几个盲化密钥是否来自同一个根密钥。这些就是盲化的性质。一句话概括盲化：x = (x * large_random_int) mod m。

支付到 bitcoin 地址时，你可以为每次使用生成一个新的盲化密钥。

然后你还需要能生成这样的签名：无法看出两个签名出自同一个私钥。我不确定「总是用不同的盲化公钥签名」是否已经具备这个性质。如果不具备，我想就该群签名出场了。有了群签名，可以做到某样东西被签了名，却不知道是谁签的。

举个例子，假设某次不得人心的军事行动必须下达命令，但没人想作为下令者载入史册。如果 10 位领导人都持有私钥，其中一位可以签署命令，而你不会知道是谁签的。

对，是技术限制。按比特币地址发送，是把交易注入网络，由收款方从网络上发现它。你们并不直接连接，对方当时也不必在线。

我非常想找到附带一条短消息的办法，但问题在于，全世界都能看到这条消息。无论你怎样反复提醒人们这条消息毫无隐私可言，它都会是一起等着发生的事故。

遗憾的是，ECDSA 只能用于签名，不能加密消息，而我们需要的正是 ECDSA 的小体积。RSA 能加密消息，却比 ECDSA 大上好多倍。

下单付款的推荐方式：

1) 商家有静态 IP，客户带备注直接发过去。

2) 商家新建一个比特币地址交给客户，客户发到该地址。这将成为网站软件的标准做法。

RSA 对 ECDSA：关键不在可执行文件的体积，而在数据的体积。我当时想，如果区块链、比特币地址、磁盘空间和带宽需求都要大一个数量级，那就不实用了。另外，即便用 RSA 传消息，整个比特币网络仍用 ECDSA、只对消息部分并行使用 RSA 也更合理。那样的话，到目前为止已实现的一切都可以原样保留。

这件事可以等很久之后再想最优做法。它可以用独立的（也许是现有的）电子邮件或 IM 基础设施来传消息；也可以不用 RSA，只在交易里放进消息的哈希，以证明这笔交易对应消息中描述的订单。消息里必须带盐，否则没人能阻止别人暴力破解哈希、还原短消息。

theymos 已经说过了……ECDSA 并不支持加密消息。只支持数字签名。

ECDSA 无法加密消息，只能做签名。

永久记录明文消息给所有人看是不明智的。那会是一个等着发生的事故。

如果要有一个消息系统，它应该是与 bitcoin 网络并行的独立系统。消息不应记录在区块链里。消息能用 bitcoin 地址的密钥对签名，以证明来源。