Yes, I'm aware of possible misuses of my software, and I told about them earlier in the thread. It does not check TX it relies. This is bad, and out-of spec, or is it? (Oh, wait, spec is the Satoshi client code, need to check what it says about it).
Actually, the client (and other documents) clearly define the nServices bit NODE_NETWORK to indicate verification and full node status. Though you may end up relaying crap and getting banned as a DoS'er by full nodes, if you just did SPV verification and relayed without NODE_NETWORK it would technically be within spec (though non-optimal).
Verifying TX is my next goal.
Full verification or SPV verification? In any case, that is very good news.
There is connection limit (in config.erl, it's 1000 by default). It does have incoming connection support (not limited, counted towards 1000). For it to work, you must configure your external IP in config.erl.
OK, I did not see that it could accept incoming connections, in any case, that is very nice. I would, however, like to point out that the two types of connections represent two completely different purposes:
Incoming connections allow you to serve data to other peers who need connections. It helps the network by using your bandwidth to provide relaying.
That said, we cant purely rely on incoming connections because there is no way to know if they are all connections from one attacker. So we make a few outbound connections to make sure we have diversity.
I'd like to note that more outbound connections by everyone does not result in greater propagation speed. It eats /tons/ more bandwidth and you will end up shooting yourself in the foot.
How many nodes does testnet have? I'm interested in maintaining thousands of connections to reduce network diameter and propagation speed. I'm sure network part will work with 10 (or 100) nodes.
Again, attempting to create more connections to reduce network diameter ends up shooting yourself in the foot, it actually wont end up decreasing propagation speed. Furthermore, propagation speed isnt an issue in today's Bitcoin network. Sure, miners want the best propagation speed they can find so they dont mine stale blocks, but the large pools mostly have private peering with other large miners to ensure that it is never a problem for them. P2Pool also relays the minimum data required to relay blocks found to all p2pool nodes in addition to announcing them on the Bitcoin network at the same time, ensuring the blocks get introduced to the Bitcoin network at many points at once. Finally, if you simply allow incoming connections, you will almost always get around a hundred nodes after a day or two, which results in really damn fast relaying for anything you generate.
It does not do more than 1 connection per host:port pair, and tries such pairs only once in lifetime. So, impact on each node is minimal (as long there is not many of nodes running my software).
"Impact of my DDoS tool is very small, as long as only a few people are running my DDoS tool." You see the problem here...
Again, no one has issues with some of the ideas of this project, its some of its specific implementation details that are broken.