回复：一些建议
原始发布页
打开来源页面查看 1 个交叉存档
有帮助的建议，谢谢。
引用自：madhatter 于 2009 年 12 月 09 日 05:34:46 AM
- 当比特币软件与对等节点建立连接（客户端 TCP 套接字）时，让客户端发送握手字符串。目前是由服务器（服务器 TCP 套接字）发送握手。我的理由当然是匿名性。ISP 太容易对客户端进行端口扫描，并检测出它们正在运行这个程序。
这是个好主意。接受连接的一方只需在收到有效握手前不发送任何内容。任何端口扫描只能得到一个不会主动表明身份的死连接。
引用
- 在握手期间使用某种加密（与上面的陈述/请求有些相关），以便在 DPI（深度包检测）期间混淆这个软件的身份。我确实是在考虑中国/伊朗等不自由（指自由权利）国家的人们。
我考虑过最终用 SSL 加密所有连接。我认为对 DPI 来说，任何低于 SSL 的方案都没有意义。也许更直接的解决方案是通过 TOR 连接，0.2 版本将支持。
引用
- 需要某种 API，让这个系统可以与网站集成，以提供即时启用的服务。一个简单的 https 收据机制会产生奇效。让客户端把每一笔收到的付款及其所有相关信息发布到一个 https URL，并提供状态更新。最好还能有一个对外付款机制。这样就可以自动向外付款（以及批量付款）。状态可以通过 https 收据接口返回。
这是 0.2 之后议程上的主要事项之一。
引用
- 静态端口/随机端口。提供一项设置，随机分配它运行时使用的端口。（对于限制非常严格的防火墙，也要能够静态设置。）
是的，如果端口号总是相同，其他隐蔽功能就有点没意义了。
引用
- UPnP 支持。让客户端自动在上游路由器上创建端口转发。默认启用。可以在选项菜单中关闭。
我很期待尝试 UPnP。大多数 P2P 客户端通常默认启用 UPnP 吗？
引用
- 能够为 *NIX 系统编译无头（仅控制台）安装版本。也要能够只作为网络服务运行。也许可以提供一个能通过 telnet 连接的控制端口（或者甚至用 unix 套接字也可以）。
我还在考虑怎样最好地构建管理接口。也许用命令行命令与后台守护进程通信，查询收到的交易并发起发送转账，这样会更便于自动化。或者在 80 以外的端口提供 HTTP 浏览器管理界面？
英文原文
展开英文原文
Helpful suggestions, thanks.
Quote from: madhatter on December 09, 2009, 05:34:46 AM
- 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?