原始文献 / 论坛帖 / Re: A few suggestions
Re: A few suggestions
Bitcointalk · 2009-12-09 18:45:10 UTC
建议很有帮助，谢谢。
引用自：madhatter，2009 年 12 月 9 日 05:34:46 AM（https://bitcointalk.org/index.php?topic=12.msg40#msg40）
当比特币软件与一个节点建立连接时（客户端 TCP 套接字），让客户端先发送握手字符串。现在是服务器端（服务器 TCP 套接字）先发送。我的理由当然是匿名性。ISP 对客户端做端口扫描、从而发现它们在运行这个程序，实在太容易了。
这是个好主意。接受连接的一方只需要在收到有效握手之前不发送任何数据。任何端口扫描都只能得到一个不会主动暴露身份的死连接。
引用：
在握手过程中使用某种加密（与上面那条建议/需求相关），以在 DPI（深度包检测）面前混淆这个软件是什么。我真正想到的是那些不自由（指自由层面）国家的人，比如中国/伊朗。
我考虑过最终给所有连接加上 SSL。我认为，面对 DPI，任何比 SSL 弱的手段都没有意义。一个更直接的办法可能是走 TOR 连接，0.2 版会支持。
引用：
需要某种 API，以便这个系统能和网站集成、提供即开即用的服务。一个简单的 https 回执机制会大有帮助。让客户端把每笔入账支付连同所有相关信息 POST 到一个 https 网址，并提供状态更新。另外出账支付机制也很好，这样就可以自动（批量）向外付款。状态可以通过 https 回执接口返回。
这是 0.2 之后议程上的主要事项之一。
引用：
静态端口/随机端口。加一个设置项，随机分配运行端口（防火墙特别严格时也可以设为静态）。
是的，如果端口号永远不变，其他隐身手段就没什么意义了。
引用：
UPnP 支持。让客户端在上游路由器上自动创建端口转发。默认开启，可以在选项菜单里关掉。
我很想试试 UPnP。大多数 P2P 客户端默认都开 UPnP 吗？
引用：
能编译出无头（纯控制台）版本给 *NIX 系统。也支持只作为网络服务运行。最好有个能 telnet 进去的控制端口（甚至 unix socket 也行）。
我还在考虑管理接口怎么设计最好。也许是用命令行与后台守护进程通信，查询收到的交易、发起转账。那样对自动化更友好。或者在 80 以外的某个端口上开一个 http 接口，用浏览器管理？
英文原文
Helpful suggestions, thanks.
Quote from: madhatter on December 09, 2009, 05:34:46 AM（https://bitcointalk.org/index.php?topic=12.msg40#msg40）- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
That's a good idea. The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake. Any portscan would only get a dead connection that doesn't volunteer to identify itself.
Quote- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.
I have thought about eventually SSLing all the connections. I assume anything short of SSL would be pointless against DPI. Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2.
Quote- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.
That's one of the main things on the agenda after 0.2.
Quote- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).
Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.
Quote- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.
I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?
Quote- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).
I'm still thinking about how best to structure the management interface. Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. That would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?