隐私与匿名

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

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

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

它隐藏的是 bitcoin 地址吗？是这么回事吗？好，如果是这样，我可能明白了。

密码学也许提供了一种「密钥盲化」的办法。我做过一些研究，相关内容很晦涩，不过也许能从中找到办法。「群签名」可能与此相关。

这里有一些相关领域的资料：

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

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

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

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

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

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

我起初也这么想。但后来又说服自己改变了看法。

你这里又回到讨论现有的 Bitcoin 系统了吗？

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

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

1) 给它看一直追溯到最初挖出的那枚比特币的完整历史。

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

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

还在琢磨这个想法……

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

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

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

网络跟踪一堆相互独立的 outpoint。它不知道它们属于哪些交易、金额多少。客户端可以查询一个 outpoint 是否已被花掉，并提交一个满足条件的 inpoint 来标记它已花费。网络保存该 outpoint 和证明其已花费的第一个有效 inpoint。inpoint 签署的是由其关联的下一个 outpoint 和盐值一起计算出的哈希。因此，只要知道盐值，就能私下证明该签名对应某个特定的 next outpoint；而公开网络并不知道下一个 outpoint 是什么。

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

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

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

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

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

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

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

我认为我们应该淡化匿名这一点。随着比特币地址比按 IP 发送更受欢迎，我们不能给人一种它自动就能匿名的印象。使用假名是可能的，但你必须小心。要真正做到这一点，就必须采取预防措施。如果我们没有事先说明这一点，让大家形成合理预期，那么，一旦有人深挖交易历史，开始披露人们原以为匿名的信息，反弹会严重得多。就像 Tor 所说：

文档引文Tor 文档来源 ↗

“Tor 不会神奇地加密你所有的互联网活动。请了解 Tor 能为你做什么，以及不能做什么。”

另外，匿名听起来有点可疑。我想，需要匿名的人，即使我们不大肆宣传，也还是会自己弄明白。

我对 bitcoin.org 首页作了一些修改。更新翻译并不是特别要紧。我往往会在之后一段时间继续编辑和修正，所以如果他们想更新，应该先等等。

我删掉了“anonymous”这个词，以及那句关于“anonymity means”的话，虽然你很谨慎地写成了“……可以保持隐藏……”，删掉确实有点可惜。

我改为在底部添加了 Tor 使用说明，并紧接着说明如何保持匿名（使用假名）：“如果你想保持匿名（实际上是使用假名），请小心，不要透露任何能把你的比特币地址与你的身份联系起来的信息，并为每笔收到的付款使用一个新的比特币地址。”

现在它可以通过 Tor 自动发现初始节点，这会有帮助。

即使直到页面底部才提到匿名，我认为寻求匿名的人也早已能从其他属性推测出来，比如没有中央机构收集你的身份信息，以及比特币地址本身的样子。

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

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

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

这在我的清单上。我很快会让"你的比特币地址："窗口在当前地址收到款项后，自动显示一个新地址。

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

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

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

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

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

以求稳妥。

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

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

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

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

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

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

Bitcoin 还很新，也没有经过独立的安全分析。如果你很重视隐私，使用 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 小时不再尝试。

这事我想了一阵了。我想先给 .onion 地址加上后端支持和连接能力，然后在此基础上继续推进。

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

有用的建议，谢谢。

其他参与者原话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 接口，用浏览器管理，如何？

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

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

其他参与者原话bitcoinbitcoin

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

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

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

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

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

启用代理设置并重启比特币后，不到一分钟就有了第一个连接，最后甚至达到了 8 个连接。我不知道它们是否真的都经过 TOR。Netstat 只显示 2 个到 localhost:9050 的连接，还有 7 个从本地 8333 端口到其他位置的连接。（显示的某些连接可能已经断开。）不知道为什么，我运行程序的文件夹里没有 debug.log。

debug.log 已移到数据目录“%appdata%/bitcoin/debug.log”。

7 个传入、2 个传出，听起来基本符合预期。

我上一次 SVN 提交重写了选择连接地址顺序的代码，按最近看到在线的时间依次尝试，所以如果 IRC 不可用，应该也能在更合理的时间内连上。IRC 实际上只在为第一次连接提供种子节点时才需要，不过我们一直把它当作加快连接的拐杖。

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

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

如果某些能接收传入连接的节点愿意把自己的 IP 写进程序，就可以自动获得种子节点。或者可以在 Wiki 页面上公布一些 IP 种子地址并附上说明。

wiki 页面听起来是个不错而且能快速实行的办法。我可以在那里更新自己的 ip，也可以请其他人这样做。等 Linux 版本能运行起来，就更容易在大多数时间在线、拥有静态 IP 的服务器上设置节点。随比特币附带一个静态 ip 列表，再加上对等节点交换协议，会很棒。这样就不需要 IRC 服务器了。

那就太好了。只有 TOR 用户需要它，所以说明里的“bitcoin -proxy=127.0.0.1:9050 -addnode=<someip>”，someip 可以是一个真正的静态 IP，旁边放上任何人都能添加自己 IP 的 wiki 列表，或者它的链接。应该有一个链接指向这个可选步骤：既然你现在能接收传入连接了，如果你有静态 IP，就把它加到这个列表里。

你觉得想匿名的人，是想完全隐身，一次都不在没有 TOR 的情况下连接，让谁都不知道自己在用比特币，还是只想在进行任何交易之前切换到 TOR？只有想完全隐身，才需要通过 -proxy -addnode 手动指定种子节点。这很容易弄错；如果一开始正常运行比特币，它马上就会自动开始连接。

Martien van Steenbergen 写道：

引用的来信Martien van Steenbergen来源 ↗

很有意思。这与 David Chaum 的匿名数字货币相似吗？他的构想能保证货币匿名，除非规则被破坏，也就是同一笔钱被花费多次。一旦出现这种情况，“造假者”就会立即被公开揭露。

相似之处在于，币都使用数字签名；不同之处在于保护隐私和防止双重支付的方法。比特币的收款人可以检查，这是否是第一次花费，第二次花费不会被接受。它没有在事后揪出双重支付者并公开羞辱的离线模式，因为那会要求参与者具有身份。

为保护隐私，密钥对只使用一次，每笔交易都使用新的密钥对。谁持有一个币的私钥，谁就是它的所有者。

当然，最大的区别是没有中央服务器。这是 Chaum 式系统的致命弱点：中央公司关门，货币也就停止运作。

引用的来信Martien van Steenbergen来源 ↗

另外，比特币的货币供应量是否有限（因而必须管理）？还是说，货币恰好在交易时创建？

货币供应量有限。流通量将是 21,000,000 个币。交易只转移所有权。

谢谢你的问题，

Satoshi

http://www.bitcoin.org

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

永久记录明文消息给所有人看是不明智的。这样做迟早会出问题。

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

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

下单付款的推荐方式：

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

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

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

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

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

我非常想找到附带一条短消息的办法，但问题在于，全世界都能看到这条消息。无论你怎样反复提醒人们这条消息毫无隐私可言，迟早还是会有人因此出问题。

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