Bitcointalk · The case for removing IP transactions

中本聪,2010 年 9 月 19 日

SN-2773 已核对来源,附原文与上下文。

阅读语言
中文译文

最好默认禁用按 IP 收款,除非你明确打算用它。这是一大片无人使用的攻击面,并无必要默认开放。

在商店场景下,你通常仅仅想让顾客通过你的自动化系统付款,它仅仅发放与特定订单和账户关联的 bitcoin 地址。随机、无身份的支付自愿发到服务器的 IP 地址上,并无任何用处。

总的来说,按 IP 发送的实用场景有限。倘若不经代理直连,中间人风险或许能够容忍,然而没有隐私。倘若你用隐私代理,中间人风险则高得不可接受。倘若我们费劲实现了 SSL,通常仅仅大商家才愿意花功夫拿 CA 证书,而这些场景大多仍然用 bitcoin 地址更好。

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

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

我给开关用了不同的名字,因 "-allowiptransactions" 听起来像包含发送。倘若这个开关有更好的名字,我们能够再改。

ORIGINAL · 英文原文
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.
上下文
← 上一条 SN-2773 · 当前 下一条 → 在档案中查看完整主题串 →
来源
Bitcointalk 原始链接 ↗ 记录编号 SN-2773