SN-10031 附来源、原文与上下文。
很高兴看到，你考虑过比特币客户端向自己付款的情况，并在交易日志里给出了合适的说明 (:
I'm glad to see you considered the possibility of a BitCoin client making a payment to itself and have an appropriate description in the transaction log (:
我这么做，主要是为了抓取交易期间的网络数据包，进行分析。由于不知道你的数据包结构，我只能在包里看到一点明文信息，主要是交易详情里显示的姓名、备注等内容。线路上还出现了‘version’和‘reply’等其他几个字符串，不过剩下的内容就很难辨认了。
I did this primarily so that I could get a packet capture of the network traffic during a transaction to analyze. Without knowing your packet structure, I only see a bit of cleartext information in the packets, mostly just what is shown in the transaction detail such as name and comments. There are a couple of other strings that show upon the wire such as 'version' and 'reply', but the rest is pretty cryptic.
思考交易时，我意识到，除了 IP 地址或比特币地址，没有其他可识别的信息。对于通过 IP 进行的交易，比特币客户端似乎相信，自己连接到的 IP 确实就是这笔交易预定的收款人。发起中间人攻击、窃取收到的付款其实很容易。设想一位同事和我的工作站都在同一个局域网里。我如果居心不良，可以在本地广播域里进行 ARP 欺骗，让所有发往他工作站的流量都经过我的工作站中转。我们俩都不是好员工，都玩当下流行的大型多人在线角色扮演游戏，还喜欢用比特币买卖游戏物品。我很容易监视 TCP 端口 8333 上传入的连接，把这些连接终止在我的工作站，而不再转发给他的工作站。是的，这有点绕，但能说明问题。这类攻击可以发生在交易双方之间路由上的任意一跳。如果我是美国某家大型 ISP 里作恶的管理员——你明白我的意思。
While pondering transactions, I realized that there is no identifiable information involved other than an IP address or a BitCoin address. In the case of the IP transaction, the BitCoin client seems to trust that the IP that it has connected to really is the intended recipient of the transaction. It is fairly trivial to launch a man-in-the-middle attack and steal incoming transactions. Consider the scenario where a co-worker and myself have our workstations on the same LAN. Being nefarious, I could be ARP poisoning the local broadcast domain and routing all traffic destined for his workstation through my workstation as an intermediary. Both of us, not being good employees, play the MMORPG-du-jour and like to buy and sell game items using BitCoins. I could easily watch for incoming connections on TCP port 8333 and terminate them at my workstation rather than passing those particular connections on to his workstation. A bit convoluted, yes, but it illustrates the point. This type of attack could be performed at any hop along the route between the two transacting parties. If I were an evil admin at Big ISP USA, well, you get the idea.
我建议不要允许用网络地址作为预定收款人的地址。我想，始终要求使用比特币地址来交易，会更安全一些。如果我理解这种方式是如何工作的，你只是把交易计算进区块链，再让预定收款人自己‘发现’它，对吗？另一种办法，是让网络节点提供解析服务：它们向其他节点询问某个比特币地址对应的网络地址，如果那个节点在线，等网络对这个地址达成共识后，发送方的比特币程序再直接连接过去。因为比特币地址与节点的密钥绑定，我想应该能设计一种办法，证明发送节点拥有那个比特币地址；如果是这样，就不继续进行交易。至少，如果你打算保留用 IP 指定收款人的方式，我建议允许比对双方共享秘密的哈希，或者其他中间人不知道的内容。不过，既然加密机制和生成好的密钥本来就已经具备，直接使用它们会是强得多的方案。
I would recommend not allowing the use of network addresses as the address of an intended recipient. I would think it would be a bit more secure to always require a BitCoin address and do transactions that way. If I understand how that is done correctly, you just compute the transaction into the block chain and let the intended recipient 'discover' it, correct? An alternative could be to allow the network nodes to provide a resolution service, where they ask around for the network address of a BitCoin address, and if that node is online, once a consensus is agreed upon by the network for that address the sending BitCoin application connects directly there. Because the BitCoin addresses are tied to the keys of the node, I would think that some method could be devised to prove ownership of that BitCoin address by the sending node and not to proceed with the transaction if so. At the very least I would recommend, if you intend to retain the recipient addressing by IP method is to allow for matching a hash of a shared secret between the parties or something that an intermediary would not know, but since you have the crypto in place, keys generated, etc. anyhow, using that would be a much stronger solution.
还是说我想得太多了，网络连接只是为了立即通知交易，以及传递备注之类的上下文信息？比特币程序提到要取得收款人的公钥，还做了其他几件事；从网络流量来看，它做的似乎远不止发送一条简单通知。
Or am I over-thinking this and the network connection is just to send immediate notification of the transaction and context information such as the comment? The BitCoin application mentioned getting the recipient's public key and a few other things, and there seems to be a lot more going on in the network traffic than what would be required for a simple notification.
回头再聊。
Talk to you soon,
-- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com
-- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com
我把攻击分为两类：
I group attacks into two classes:
第 1 类让你面临来自家中或公司局域网内人员、沿途互联网服务提供商管理员，以及接收方局域网内人员的攻击。第 2 类则让你面临十亿人，其中任何人都可以自行决定成为攻击者，而且只要开发出一种攻击技术，就能攻击多名受害者，取得规模效应。
Type 1 exposes you to people in your house or company on your local LAN, admins at ISPs in between, and the LAN on the recipient's side. Type 2 exposes you to a billion people who can self-select to be attackers and get economy of scale when they develop one technique to attack multiple victims.
通过 IP 发送时会请求一个新的公钥，所以，是的，它容易受到第 1 类中间人攻击。如果担心这个问题，发送到比特币地址就没有这个弱点，不过隐私上会有一点取舍。我感觉，大多数时候，人们会从未使用 SSL 的网站和未签名的明文电子邮件中取得比特币地址，而这些途径本来就容易受到第 1 类攻击，以及通过 DNS 污染实施的第 2 类攻击。
Sending by IP requests a new public key, so yes, it's vulnerable to type 1 man-in-the-middle. If that's a concern, sending to a Bitcoin address doesn't have that vulnerability, although there's a small privacy tradeoff. I have a feeling most of the time people will get Bitcoin addresses off of non-SSL websites and unsigned cleartext e-mail, which is already vulnerable to type 1 and type 2 through DNS poisoning.
一个解决办法是发送时同时使用 IP 和比特币地址（也许像 1.2.3.4-1Kn8iojk... 这样），接收方用比特币地址的公钥为新公钥签名，证明你确实是在向自己以为的那个人发送。如果系统开始用于真正的商业用途，我一定会实现这一点。另一种办法是使用 SSL。
One solution would be to use both the IP and Bitcoin addresses when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses the public key of the Bitcoin address to sign the new public key to prove that you're sending to who you think you are. If the system starts to be used for real business purposes, I will certainly implement that. Another solution is to use SSL.
就目前而言，很明显，如果你向一个 IP 发送，却没有提供接收方的其他任何身份信息，那就是盲目地发送给回应这个 IP 的任何人。
For now, it's pretty obvious that if you send to an IP, you didn't give any other identifying information about the recipient, so you're blindly sending to whoever answers that IP.
以后还会增加一个功能：可以选择加密钱包。
Another feature for later is an option to encrypt your wallet.
引用的来信Dustin D. Trammell来源 ↗如果我正确理解了做法，你只是把这笔交易计算进区块链，然后让预定接收方“发现”它，对吗？
If I understand how that is done correctly, you just compute the transaction into the block chain and let the intended recipient 'discover' it, correct?
没错。
That's correct.
引用的来信Dustin D. Trammell来源 ↗另一种办法是让网络节点提供解析服务，彼此询问某个 BitCoin 地址对应的网络地址。如果该节点在线，等网络就这个地址达成一致后，发送方的 BitCoin 程序就直接连接过去。
An alternative could be to allow the network nodes to provide a resolution service, where they ask around for the network address of a BitCoin address, and if that node is online, once a consensus is agreed upon by the network for that address the sending BitCoin application connects directly there.
如果只需要比特币地址，在后台就能确定 IP，会很方便。不过可能会有隐私或拒绝服务方面的问题。当然，在实现另一种发送方式之前，现在有充足的时间把设计想清楚，确保这是最好的办法。
It would be nice to only need the Bitcoin address and have the IP worked out behind the scenes. Might have privacy or denial of service issues. Certainly before another sending method is implemented, there's plenty of time now to fully think through the design and make sure it's the best way.
Satoshi
Satoshi
