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.



A Possible Oversight on my part, Concerning FS Corruption

One of the facts which regularly concerns me about Linux, is that we Mount a File System so that we can access its files, and that we Must Unmount it at the end of any Kernel-Session, before we can power down or restart the machine, and that failure to do so results in FS Corruption.

But there is a thought which has only occurred to me recently, about how that might not translate correctly into Windows. It could be that under Windows, there is no hidden Mount or Unmount procedure, when we boot the computer or shut it down. In the past I had always assumed that this step does exist, but that Windows keep it hidden in the BG.

If Windows has no analog to this, then the problems I was describing in This Posting, may simply be due to a weak, dodgy hard-drive on the computer I name ‘Mithral’, purely in how it functions as hardware.

Also, I should next take steps to take a closer look at OS/X, which was originally derived from some form of UNIX (‘BSD’), but which may also have done away, with any sort of Mount or Unmount taking place in the BG.



Diskeeper 2016 is definitely Better Than Version 2011 was.

Both mentioned versions of Diskeeper have approximately the same features, including to perform ‘Fragmentation-Prevention’, by caching files that are being written to the HD for longer than Windows would normally do so, in order to be able to write contiguous output blocks, and including ‘Background-Defragmentation’, for which we can schedule times of day or days of the week we want it to happen.

One fact I find odd under Windows, is that no effort is made where the user can see it, to distinguish between ‘Fragmentation’, and ‘FS Corruption’, the latter of which can also be called ‘File System Inconsistencies’. The idea in the minds of Windows software developers seems to be, that whatever we have, we have, that being, whatever is linked.

But a deeper fact which I know about Windows, is that if an efficient defragmenter is let loose on the File System, and it encounters actual FS Corruption, it will cause Windows systems to crash – to do one of those nasty reboots which the user did not tell them to do. This has led to some people not being able to get through a defrag, before the computer would crash, until those users ran a File-System Check, between reboots, using ‘Checkdisk’, which solved their problem for them.

When either version of Diskeeper is told to do a manual defragmentation, it does not go as deep, as one of its scheduled, Background Defragmentations go. This was a major reason for My Previous Posting.

What I have learned, is that the 2016 version of Diskeeper, does a much more thorough job of cleaning up the File System, even during the Background Defragmentation, which its software company no longer touts as a major feature. The software company mainly touts the Fragmentation Elimination feature. But BG-defrag having taken place successfully last night, and having produced the report it did, makes me confident again, that it was able to find FS Corruption which neither its 2011 version, nor Windows Checkdisk, were able to recognize. And so I may be able to keep the present O/S installation on ‘Mithral’.


In fact, having been able to perform heavy computation continuously from 13h00 yesterday, until 4h00 this morning, while Diskeeper 2016 was installed, and then allowing this software to do a BG-defrag, also impressed me about the idea, that at least the H/W seems to be quite stable.


(Edit : ) It would not be obvious how “Fragmentation-Prevention”, would reclaim those 13,184 blocks. But according to the System Software I studied, there is an answer. There exists Internal Fragmentation, and External Fragmentation.

Continue reading Diskeeper 2016 is definitely Better Than Version 2011 was.

OGRE 1.10 Compiled On Laptop ‘Klystron’

One of the projects which I had been working on, while my Hewlett-Packard laptop was running Windows 8.1 and named ‘Maverick’, was to compile “OGRE 1.10″ on it to the best of my ability. And one mistake which I was adhering to, was to insist on using the ‘MinGW’ compiler suite. OGRE developers had already tried to convince me to use the MS compiler, since that was a Windows computer, but I did not comply. This was particularly pedantic of me, since by now a free version of Visual Studio is available, that can compile OGRE.

So now that the H/W has Linux installed on it, I recommenced compiling OGRE, with native compilers and tools. But the results were not exactly spectacular.

One reason for the lackluster results is, the fact that ‘Klystron’ currently has ‘Mesa’ drivers loaded for its Radeon graphics card, instead of having the proprietary, binary ‘fglrx’ driver. Mesa will give it OpenGL 3.3 tops, while ‘fglrx’ would have given it OpenGL 4.5. And the latest OGRE samples include samples with Geometry Shaders, other OpenGL 3 features, and even some Tessellators, which would be OpenGL 4 features.

Apparently, when one pushes any Mesa Drivers to their limits, these will bug out and even cause the X-server to freeze. Thus, when I switched from testing the OGRE OpenGL 2 rendering engine, to its OpenGL 3+ rendering engine, I ran in to an X-server freeze.

This did not force me to hard boot, because often, during an X-server lockup, I can <Ctrl>+<Alt>+F1 to a console window, from there do a user and a root login, and then issue an ‘init 6‘ command, which will usually do a controlled reboot, in which all file systems are unmounted correctly before the restart.

There is one detail to what the Mesa Driver does, which I like a whole lot.They allow for shader code written in the language Cg to run, even though Cg is a legacy toolkit developed by nVidia, for use on nVidia graphics cards and not on Radeon.

The fact that the Mesa Drivers allow me to do that, differently from the limitations which were only imposed on me under Windows 8.1, means that with OGRE 1.10, the Terrain System finally works 100%. OGRE 1.10 uses GPU-generated terrain, whereas most graphics engines rely entirely on their CPU, to create terrain. The earlier inability to get terrain to work with this system, was more crippling than anything else.

But as long as I am not using the ‘fglrx’ drivers, all attempts to get OpenGL 3 features to work with OGRE utterly fail, including any hope of ISO surfaces, which rely on Geometry Shaders, and any hope of GS-based particles. My particles will be limited to Point Sprites then.

What one does in a situation such as this, is not just to throw out OGRE 1.10, but rather, to disable modules. And so I disabled the GL3+ rendering engine, as well as one ‘HLMS Sample’, and am now able to get many of the samples to run, including, importantly, the Terrain Samples.



Also, there remains an advantage to using Mesa Drivers, which was pointed out to me already on the Kanotix site. The Mesa Drivers allow hardware-acceleration of high-bandwidth, 2D video streams, via ‘vdpau’, while if I was to use ‘fglrx’, the decoding of MP4 Videos would be limited to CPU decoding, which is in itself lame, if we ever wanted to watch serious video streams. And since that laptop has a screen resolution of 1600×900, wanting to watch videos on it eventually, remains a very realistic prospect.



(Edit : ) I suppose that one question which I should be asking myself, about why perhaps, the OGRE 1.10 GL3+ Rendering Engine does not work, would be whether this could be due to some incompatibility with the GL3.1 Desktop Compositing which I am already running on the same machine. There have been past cases, where OpenGL 2 from an application did not agree with OpenGL 2 Desktop Compositing, but those cases have generally been solved by the developers of the desktop managers.

On ‘Klystron’, I have rich desktop effects running, that use GL 3.1. So it does not seem obvious, that the Mesa Drivers as such, have problems implementing GL 3.

Also, there is a follow-up thought, as to why maybe, Cg was not working before. Whether or not our graphics cards support Cg, it is a necessary component of OGRE, to build their Cg Program Manager. Under Windows 8.1, I was always unsure of how to provide the OGRE Dependencies when building OGRE. But among those dependencies I always linked in a file named ‘Cg.dll‘, the origin of which was unknown to me.

It is exactly the sort of goofy mistake I would make, perhaps to have taken this DLL File from the install folders of Cg on ‘Maverick’, but for some reason simply to have taken a 64-bit DLL, into my 32-bit OGRE build, or to have taken a DLL from somewhere, which may not have been compatible for some other reason.

At least when we install dependencies under Linux from the package manager, such issues as linkage of code and location of folders, are also taken care of by the package manager. So I am sure that the Cg Program Manager belonging to OGRE, recognized the nVidia Cg packages when compiling now. It is just a bit odd that those were native Cg libraries with header files, while my graphics drivers remain the Mesa Drivers.