I decided to go to a broadcast method, which is theoretically more bandwidth intensive, but due to the redundancy needed to ensure the time critical packets got to the destination, it was using the bandwidth anyway. And if the design is a broadcast method, it means that we can add point to point encryption for all the pubkey based comms.
So I did.
I also streamlined the broadcast mechanism and added a broadcasting service that the LP nodes do for client nodes. This allows any client to request a broadcast of an encrypted packet to the network. Now I am tracking the number of redundant packets sent to make sure we aren't flooding the network.
PULL dup.1 (30 / 139) 21.6% encrypted.0 recv.4015931715 [7b 22] vs 43 41 U.102
About 20% redundant packets, which is not bad at all. Since the atomic swap is using pubkey based messaging, this means that the atomic swaps are done in the dark. Of course there are still indirect means that can be used to determine who did a trade at a certain time, just by looking at the blockchains, so it isnt anything like zeroknowledge level privacy, but having all the trade details under encryption certainly makes it harder for others to know what is going on.
This will of course create a bit of a problem when trying to gather stats, but I have an idea on how to do that without infringing on the privacy.
As I have discussed before nodes that cant bind ports that other nodes can connect to (virtually all home isps!) is the hardest case. Of course we want to support this case as the alternative is that anybody that wants to post an order long term would need to run a vps. The new broadcast mode is designed to work much more reliably with such nodes. And in fact was able to list some JUMBLR...