Author

Topic: Implemented STUN protocol for cryptocurrency (Read 1468 times)

member
Activity: 102
Merit: 12
August 13, 2014, 06:54:10 AM
#3
> Are you currently considering implementing a Port Restricted Cone of some sort?

Implementing any sort of NAT is not function of cryptocurrency wallet. Therefore, we don't planning to implement it in the EMC-wallet.

If you mentioned "support Port Restricted Cone NAT" in the EMC wallet - again, we think, this is impossible directly,
because of _both_ peers can be located behind their own NATs (there is no dedicated server), and no one of them can control source port.

About indirect support this type of NAT - it is doing automatically, when node increases connectivity (collect big list of peers),
and create path around the problematic devices. And current STUN-solution is doing this job - disallow to degrade network connectivity.

> I should probably modify those lines in my wallet's local-source from non-working one to something like: whatsmyip.org

If you will do so, don't forget to change "parser part", too.
Because of text WEB-oriented protocol is not standardized, Bitcoin wallet uses prefix-search code (parser), specific for each WEB-site, to find correct position of IP-address in the answer.
legendary
Activity: 1610
Merit: 1000
Well hello there!
Interesting concept.  I know STUN server's have been used for a number of year's for NAT traversal for VoIP devices located behind NAT.  Are you currently considering implementing a Port Restricted Cone of some sort?

Definitely agree that having only a single source for current web-based lookups is not a good thing.  dyndns takes a hit and we have some serious problems imho.

I should probably modify those lines in my wallet's local-source from non-working one to something like:
whatsmyip.org (as a secondary).  Honestly I'm a bit surprised there is only a single fail-over (albeit invalid) currently in the system.
hero member
Activity: 535
Merit: 501
EMC
For the first time in the history of cryptocurrencies, is used STUN protocol to obtaining an external IP address, instead of WEB-service.

  This problem is already discussed in the cryptocurrency community, for example, here:
http://www.reddit.com/r/Bitcoin/comments/29zx7z/bitcoin_core_uses_showmyip_as_a_centralized_hard/

But, without any positive outcome.

Problem description:

  Bitcoin and it’s descendants (PPC, QRK, etc) – all of them uses same public WEB-server for obtain external IP.
There is two public servers, hardcoded into a wallet program:
- http://checkip.dyndns.org
- http://www.showmyip.com

For source code, see https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp, function GetMyExternalIP()

  What is interesting: 2nd server http://www.showmyip.com is out of service nowadays. So, all Bitcoin and altcoin networks currently
dependent  on single WEB-server: checkip.dyndns.org. If this server will gone, then coin network will not died, but dramatically lost stability.
This will happening, because of peers wouldn't able to advertise  (represent) another peers into network, and peer network
connectivity will be decreased.

  Moreover, current WEB-mechanism for obtain external IP is based on non-standardized human-oriented text protocol.
Therefore, if site owners will modify output format, (for instance, for better reading), then all coin wallets will be unable
to parse and understand answers, and results will be as same as server down.

  In addition, dyndnd.org’s owners able to analyze WEB-server logs, and collect list of IP addresses, where is running coin wallets
and request timestamps, if is not doing this right now (request signature is hardcoded and well known, and easy to distinct).
If we remember, users usually runs wallet just before start some transactions, then we aware:
analyst can correlate wallet start and transaction time, and link it to IP address.
This is serious compromise of coin users anonymity.

Our solution:

  We substituted current non-standard, hard-weight (based on TCP/HTTP) protocol to protocol, based on mature standard RFC3489 (STUN),
designed especially for this purpose. See: http://en.wikipedia.org/wiki/STUN . This is lightweight, UDP-based protocol, used in SIP-based
applications (VOIP, IP-video) for 10+ years. And since it is standardized, we can use unlimited list of  servers for request, and always be
sure: EmerCoin wallet can parse/understand answer from anyone.

  Currently, new EMC-wallet for obtain IP address uses 47 STUN-servers, distributed worldwide, and request sequence is random. Therefore,
nobody can collect significant list if our wallets. Moreover, we performed some steps for randomize signature request, and for server is difficulty
to distinct EMC-wallet request from request, sent by IP phone or softswitch.

Therefore, we reached our goals: removed dependency from centralized server, increased network stability and provide real  anonymity.

EmerCoin team.
Jump to: