Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMÌ<div class="post">Helpful suggestions, thanks.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=12.msg40#msg40">Quote from: madhatter on December 09, 2009, 05:34:46 AM</a></div><div class="quote">- 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.<br/></div>That's a good idea. &nbsp;The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake. &nbsp;Any portscan would only get a dead connection that doesn't volunteer to identify itself. <br/><br/><div class="quoteheader">Quote</div><div class="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.<br/></div>I have thought about eventually SSLing all the connections. &nbsp;I assume anything short of SSL would be pointless against DPI. &nbsp;Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2. &nbsp;<br/><br/><div class="quoteheader">Quote</div><div class="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.<br/></div>That's one of the main things on the agenda after 0.2.<br/><br/><div class="quoteheader">Quote</div><div class="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).<br/></div>Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.<br/><br/><div class="quoteheader">Quote</div><div class="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.<br/></div>I'm looking forward to trying UPnP. &nbsp;Do most P2P clients typically have UPnP enabled by default?<br/><br/><div class="quoteheader">Quote</div><div class="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).<br/></div>I'm still thinking about how best to structure the management interface. &nbsp;Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. &nbsp;That would be more automation friendly. &nbsp;Or what about an http interface on some port other than 80 to manage it with a browser?<br/><br/></div> text/html