原始文献 / 论坛帖 / Re: The case for removing IP transactions

Re: The case for removing IP transactions

Bitcointalk · 2010-09-19 21:49:30 UTC

AuthorSatoshi Nakamoto
TitleRe: The case for removing IP transactions
Date2010-09-19 21:49:30 UTC
ForumBitcointalk · 原文

最好默认禁用按 IP 接收,除非你明确要用。这是一大片没人用的攻击面,默认不该开着。

店面场景下,你通常只想让客户通过你的自动化系统付款,系统只给出与特定订单和账户关联的比特币地址。主动发到服务器 IP 的随机匿名付款没什么用。

一般来说,按 IP 发送的用处有限。如果直连不用代理,中间人风险也许可以忍,但没有隐私。如果用隐私代理,中间人风险高到无法接受。就算我们费劲实现了 SSL,通常也只有大店面会去搞 CA 证书,但那些场景大多还是用比特币地址更好。

我把这个改动上传到了 SVN rev 156。启用的开关是 "-allowreceivebyip"。

这个版本的发送方会收到错误 "Recipient is not accepting transactions sent by IP address"。旧版本的发送方会收到 "Transfer was not accepted"。

我给开关起了个不同的名字,因为 "-allowiptransactions" 听起来像包括发送。如果有更好的开关名,我们可以再改。

英文原文

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.