Topic: Any way to improve Bitcoin Core when operating in hostile environments? (Read 2038 times)

I barely have time to post here so thanks for your "advice" but I'll just keep on working on what I am working on (it isn't really a big deal if I simply stop running Bitcoin Core).

Will lock this topic now as I think it has come to a conclusion.

Look, without you posting packet traces nobody's going to help. People who actually come to China for a short stay tend to use the hotel ISPs where problems like yours are impossible to reproduce. General growth of traffic in China is so high that every couple of months people there do experience problems purely from more competition over the limited resources.

Grab some packet captures and post it! You are an experienced programmer not some random newbie!

As stated the slowdown started at least mid last year and upgrading to 0.10.0 hasn't changed anything noticeably in that regard.

For certain using UDP for VPN basically stopped working a few months back (after further "upgrades" to the GCF).

I think probably the best bet for now would be to run locally (not tunneling) with a list of seed nodes within PRC (if any networking expert plans to come to China for a holiday maybe they could have a play "from the inside").

Without sample packet captures/traces (with the true IP addresses zeroized) nobody's going to help you much.

I no longer have access to the front-end routers/statistics at my corporation, but from the little I see in my department there is an ongoing plague of disabling proper http://en.wikipedia.org/wiki/Path_MTU_Discovery together with more and more of Internet hookups supporting less than default MTU (less than 1500). This is done to supposedly protect against DDoS attacks (PMTUD uses ICMP Fragmentation Needed packets).

Bitcoin is particularly badly affected by this issue (slowdowns because of MTU too high) because it is tuned to using very large TCP socket buffers and also tends to send humongous amounts of data without any high-level handshaking (unlike e.g. Bittorrent).

By the way: how is Bittorrent working for you? Both with UDP transport enabled (best case) and with UDP transportdisabled (to make it more like Bitcoin P2P)? (I'm not talking about udp:// or dht:// trackers, I'm talking about peer-to-peer transport using http://en.wikipedia.org/wiki/Micro_Transport_Protocol .)

Finally, did the slowdown started occurring after the 0.10.0 release? I've noticed a great increase of incoming connections from that release on my nodes and my upload bandwidth throttles started triggering all the time after that release. There is apparently Bitcoin-network-wide 0.10.0 abuse going on both on mainnet and even on testnet since last few hours.

Edit: To quantify the last paragraph: My nodes average latency was about 200ms (as shown by https://getaddr.bitnodes.io/ ). Since 0.10.0 went public it started peaking above 2000ms, I had to reduce the number of allowable incoming connections and change QoS settings to get it back down).

Bitcoin testnet seems to actually work much better (but that maybe simply due to much less traffic).

In general it appears since the latest "upgrades" to the GCF your choice of port matters little. Even my client is now having troubles running a (plain HTTP) web-server (and they have tried using numerous different ports).

For HTTPS that goes "outside" of PRC all traffic appears to be throttled (and often sessions get killed) and within China is basically restricted to certain fixed IP addresses.

Bitcoin traffic appears to have started to be targeted by the GCF around mid last year (although I can't remember for certain exactly when I noticed how slow syncing had become).

We had some of our employees move back to China (rural mainland, don't remember the details) and he had continued to use our tunneling VPN setup. We were using IPsec AH-only (not the most common ESP). This is a VPN technology that doesn't use encryption (Encapsulating Security Payload) but only authentication (Authentication Header). There wasn't any overt blocking or slowing down of our traffic, besides the usual problems one would encounter anywhere with the rural DSL provider.

IPSec AH is fully supported in Windows since XP, other OS-es supported it even earlier. It is also well supported by the very cheap Netgear Prosafe VPN/firewall devices, we've used FVS114 and FWAG114. Those are "business class" but have "home/residential" prices. Now they are officially obsoleted, don't know the replacements, but we still have them deployed and in use in many locations.

If you want to try it: do test this first on a LAN between two computers and then between same two computers over the same local ISP. Only after those tests are successful try intercontinental tunneling that could be really affected by the Chinese government censorship.

AFAIK there are no commercial providers for the AH-only service, you'll have to have your own tunnel exit somewhere in your homeland.

My information is couple of years old, Bitcoin did exist then, but probably wasn't an issue. Aside from the regular business use it was used (and it was helping unthrottle) with Bittorrent.

Edit: Also, please post some additional information regarding what you are observed as being blocked/throttled:

1) Bitcoin mainnet vs. Bitcoin testnet
2) incoming vs. outgoing connections to/from TCP port 8333/18333
3) does the non-coin-related TCP/IP traffic over the same ports flow properly?

The DNS lookup filtering was what they did 10 years ago - they have moved on a long way since then.

Now if you tunnel to outside it *can tell* no matter what port you use and it will simply throttle you down to the 1980's (if it doesn't kill you with purposely injected bad packets).

Just a silly idea, what if you set up a website on a server outside of China (with domain, ssl certificate) and then create an ssh proxy tunnel through ssl through which Bitcoind establishes all its connections?

The connection is basically like any other HTTPS connection to a website.

EDIT: Do HTTPS connections get interrupted/throttled by GFC?

HK is *not China* (in terms of the GCF).

The GCF does not operate in HK so anything you have in HK is *useless* in mainland China.

Perhaps you don't understand that I cannot even do decent internet speeds to HK?

We operate Checkpoint and Citrix SSL VPNs out of HK as a tertiary DC for our world wide employees without issue.  While these are definitely bussiness class appliances I am sure there is a providor out there using similiar equipment you could SSL VPN too.

SSL VPNs are blocked (apart from a few very expensive ones - you can probably understand how that works) and even ones using UDP don't work any better now (or ICMP if you're thinking they haven't worked out that already).


Tunnels work but are "slowed down" to the point of 9600 baud in general (as soon as the traffic goes outside of China). The GCF *detects* encryption and either "kills it" or "slows it down to a snail's pace" (I have one other way around it but I am not going to publish that).

The 3rd world war *is the internet* and I am seeing the "front line" (it will become more apparent to others in the next few years I think).

You can use SSL VPNs through the GCF without being effected.  Ipsec and L2TP protocols are blocked.

You could also use an encrypted traffic through a GRE tunnel across the GCF.  I do not think GRE is blocked is blocked by it.

There are ways (and I won't mention any details as this topic is most likely being "watched") but unfortunately unless you have very high-grade commercial internet (not easy to get without a properly registered Chinese company) your bandwidth just ends up being like a 9600 baud modem (i.e. nearly useless).

It is a guessing game (as you might have guessed(, how about private tunneling? Don't think it will increase the amount of nodes in China, but will allow your node to stay up to date? With Tor can you not select your nodes?

Just a thought: there are several mining nodes in China. There must be a way.

Won't work here (if you can name it then it is already blocked - the people that do the GCF are aware of every project going on).


Not surprised at all (am probably going to give up trying to run a node myself).


I was hoping that the headers stuff might make some difference (but seemingly not).

I2P? Freenet? JAP?

https://getaddr.bitnodes.io/nodes/?q=China
Yup, seems shrinking.

Time for Jeff G. to get that satellite up and running

Why would you think the new version would be better? Did you suggest any code improvements regarding it?

Recently I find that Bitcoin Core has become almost unusable in China (due to either direct attacks by the GCF on use of the protocol or indirect attacks on anything that comes from outside of China).

I had hoped the new version would help but after testing it for hours today it is no better (and I don't think I can *ever* catch up the blockchain now without either forking out for an expensive VPN or physically leaving the country).

What the GCF does is attack all traffic it doesn't like (that includes anything encrypted that comes from outside the country and any ports or IP addresses they don't like within the country which of course includes Bitcoin).

It crashes connections regularly (which still results in general protection failures in Bitcoin Core even though I read some of those had been addressed) and makes it impossible to even try and use Bitcoin Core at the same time as use your web browser or nearly anything else (your connections just get stuck in some sort of GCF sticky glue that makes the 1980's seem fast).

I don't know if there is anything that can be done but I do worry that soon there will be very few people running full nodes in China.

Please don't suggest TOR as that doesn't work in China (and 99% of VPN's don't either).