Bitcoin-Core P2P Client Has UPnP.

I use a Bitcoin client, which is called “Bitcoin Core“. This is a version of Bitcoin, based on Peer-To-Peer protocols. This version of the wallet-program should not be confused with the Android version, which some people have on their phones, and which is Not P2P.

Several people who use the P2P version of this wallet-program, which builds our local copy, of the global block-chain, on a zero-trust basis, have observed that they leave their client running 24/7, yet that they do not seem to be functioning as a full peer. As a full peer, their computer can act to facilitate Bitcoin transfers. Even when not being used as a full peer, this version of the program will connect with up to 8 other peers – using outbound connections – and will use these connections to keep its internal version of the block-chain – and therefore their wallet – synced with the rest of the network.

So after some time, what people may simply ask is, ‘Why don’t I receive incoming connections, from other wallets, expecting me to help complete their transactions?’ This would be a reasonable question, yet gurus elsewhere have given a wrong answer.

In general, this P2P Node needs to listen on TCP Port 8333. Therefore, what some people expect, is that they need to establish a port-forwarding rule on their router, which forwards TCP Port 8333 to whichever machine on the LAN is running Bitcoin Core. The advice has sometimes been given, that if you forward this port, you will start receiving massive numbers of inbound connections, and will become useful to the network.

There’s a slight problem with this version of an explanation. Bitcoin Core has the ability to use ‘UPnP’, which is also known as “Universal Plug-And-Play”. What UPnP does, is allow individual clients of our LAN to open a required port on the WAN-side of the router, such as TCP Port 8333 if need be. Because some users believe that enabling UPnP on their routers, makes their routers ineffective as a firewall, they disable this feature. This would be, because those users cannot even trust their LAN-clients, in which case the LAN-clients could trivially request forwarding rules, which the operators of such a LAN did not authorize.

The problem I see, is that I, personally, have UPnP enabled on my router, because I believe my actual LAN-clients to be secure, so that according to me, if they want a WAN port number, they can have it. Also, I have UPnP enabled on my Bitcoin Core P2P / wallet-program. Therefore, the LAN-client in question is requesting this Port 8333, and is obtaining it. Yet, I still don’t see a wealth of inbound connections asking for my CPU time.


There could be several reasons for this, one of which might have been, that a software-firewall on the client-machine in question could be blocking Port 8333. But I, personally have checked my software-firewall. It tells me that it is allowing all connections to and from my Bitcoin Core client a-okay. Maybe the firewall of some other participant is not?

Answer: The Windows computer my Bitcoin Core client is running on, had the LAN connection set to Public. According to Windows firewall rules, access to this program on the host machine is only granted when the network would be Private. This is to allow quick access to Public networks, which are not trusted, without reconfiguring the computer, while setting up a more-liberal set of rules for Private networks. Changing the network-type to Private seems to have solved this problem.

With certainty, my Bitcoin Core client will not show me any transactions it has facilitated, because those transactions do not affect my wallet. Bitcoin is designed to be anonymous, so that I will only see transactions which affect my own balance.



Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

The reality is that, being 52 years old and only having studied briefly in my distant past, my formal knowledge in Computing is actually lacking these days, and one subject which I know too little about, is how Push Notifications work. Back in my day, if a laptop was ‘asleep’ – i.e. In Standby – it was generally unable to be woken externally via WiFi, but did have hardware clocks that could wake it at scheduled times. Yet we know that mobile devices today, including Android and iOS devices, are able to receive push notifications from various servers, which do precisely that, and that this feature even works from behind a firewall. And so I can muse over how this might work.

I can think of two ways in which this can hypothetically work:

  1. The application framework can centralize the receipt of push notifications for the client device, to one UDP port number. If that port number receives a packet, the WiFi chip-set wakes up the main CPU.
  2. Each application that wants to receive them, can establish a client connection to a server in advance, which is to send them.

The problem with approach (1) is that, behind a firewall, by default, a device cannot be listening on a fixed port number, known to it. I.e., the same WAN IP Address could be associated with two devices, and a magic packet sent to one fixed port number, even if we know that IP Address, cannot be mapped to wake up the correct device. But this problem can be solved via UPnP, so that each device could open a listening port number for itself on the WAN, and know what its number is.

We do not always know that UPnP is available for every NAT implementation.

Approach (2) requires more from the device, in that a base-band CPU needs to keep a list, of which specific UDP ports on the client device will be allowed to wake up the main CPU, if that port receives a packet.

Presumably, this base-band CPU would also first verify, that the packet was received from the IP address, which the port in question is supposed to be connected to, on the other side, before waking the main CPU.

(Edit 12/19/2016 : Google can simply decide that after a certain Android API Number – i.e., Android version – the device needs to have specific features, that earlier Android APIs did not require.

Hence, starting from , or , Google could have decided that it was no longer a special app permission, for the user to acknowledge, to wake the device. Likewise, starting from some Android version, possessing a base-band CPU might have become mandatory for the hardware, so that the API can offer a certain type of push notification.)

Also, approach (1) would have as drawback, a lack of authentication. Any networked device could just send this magic packet to any other networked device, provided that both the IP address and the port number it is sensitive to are known.

Approach (2) would bring as an advantage, that only specific apps on the client device could be enabled to receive push notifications, and the O/S would be aware of which UDP ports those are sensitive on, so that the base-band CPU would only be waking up the main CPU, if push notifications were received and associated with an app authorized to wake the device.

Also, with approach (2), the mapping of WAN port numbers back to LAN port numbers would still take place passively, through port triggering, so that the WAN-based server does not need to know, what LAN-based port number the connected port is associated with on the client device.

But, approach (2) has as a real drawback, that a server would need to keep a socket open, for every client it might want to send a push notification to. This might sound unimportant but is really not, since many, many clients could be subscribed to one service, such as Facebook. Are we to assume then, that the Facebook server also keeps one connection open to every client device? And if that connection is ever dropped, should we assume that a sea of client devices reconnect continuously, as soon as their clocks periodically wake them?


Continue reading Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi