2020-01-24 to 2020-01-30

Server

A good part of my time was spent further tinkering with my brand new server hardware.

One issue that came up was when I made my JoinMarket Maker into a SystemD Service. Obviously I set it to After=bitcoind.service so that it will start after Bitcoin Core was loaded. Unfortunately, the bitcoind.service file in the bitcoin/bitcoin contrib/init/ directory does not wait for Bitcoin to start up completely.

It turns out that Bitcoin has to re-read the block indexes when it starts up, and it can take up to ~7 seconds to do so. During this time, it will refuse to serve any RPCs. However, the launching process exits as soon as possible, meaning SystemD thinks that Bitcoin is already perfectly fine immediately, then starts any dependencies on Bitcoin. The JoinMarket Maker, being such a dependency, is then started up very quickly after, but fails to start because it wants to ask Bitcoin some RPCs but Bitcoin is not yet ready to serve those.

What I did was write a simple script that just loops until a bitcoin-cli command succeeds, as below, and add it to ExecStartPost.

#! /bin/sh

while ! bitcoin-cli "$@" getblockcount > /dev/null 2>&1
do
sleep 1
done

Note the "$@". SystemD invocations are not “normal” and you should copy the -datadir and -conf arguments you pass into bitcoind to the above script. The above script then forwards it to bitcoin-cli via "$@". You need -datadir since bitcoin-cli wants to set up a datadir if you do not have one, and the bitcoind.service in the bitcoin/bitcoin repository makes the home directory read-only. And of course the above script should be made executable as well.

Obviously this delays startup and you might not want it for your “normal” computer that you regularly shut down and boot up every day, but for an always-on server that has to survive power interruptions and automated updates, the additional delay to wait for proper startup of other services dependent on Bitcoin is worth it.

In C-Lightning, we avoid this. Daemonization requires that a process fork twice, with the parent and its direct child exiting, and the grandchild process being the daemon that lives on. However, on C-Lightning, before the fork we establish a pipe from the parent to the grandchild process. The grandchild does some initializations and database loading, then establishes the RPC and then closes the pipe. Once the pipe is closed, only then does the parent actually exit. This technique fits better with SystemD, as it assumes the exit of the parent means the daemon is now working properly.

Coding

I had a good amount of activity and pull requests on ElementsProject/lightninh and defiads/defiads. Well for defiads mostly just me reviewing and commenting and merging.

For C-Lightning, mostly a few clarifications, and some minor modifications and improvements, including the ability to now set permissions on the C-Lightning RPC file, and to immediately finish waitanyinvoice if no unprocessed invoice is currently available. I am still working on multifundchannel, but for now I will make connect have the ability to connect to multiple nodes at once, to test out my sparks implementation. Later I will add multifundchannel_start and multifundchannel_complete and multifundchannel_cancel, I suppose.

Advice

Only a small amount of people asking about advice this week.

Tor Browser

I am slowly transitioning to using Tor Browser almost exclusively, when emulating a human operating a standard computer. Previous hardware (and maybe its LTS OS?) and ISP gave bad experience when doing anything in Tor Browser, it seems with my current ISP and hardware (OS?) Tor is almost as smooth as a commodity "home" ISP common in the places I have infested.

Some websites, however, keep thinking of my Tor Browser as a new device and keep asking for multi-factor authentication. GitHub is one of these.

This is particularly daft since I can torify git push to GitHub without being pestered about multi-factor authentication. And the worst thing you can do to a GitHub repository is to push bad code into it and wait for victims to pull and execute your code. So the multi-factor authentication pestering is just not that useful against protecting GitHub repositories, and is just an annoyance at this point.

Google applications are another set of pesterers. I should probably avoid Google applications, but GitHub is not really something I can feasibly avoid.

Zenon

With the help of Grounded Speculator, I found out that an entity called Zenon Networks is trying to somehow connect itself to Square Crypto via the coincidental similarity of “ZNN” to “Zmn”.

You might want to see the medium article that Grounded Speculator wrote. The screenshots of emails are authentic.

Briefly: I am not associated with Zenon network, I have not developed code for Zenon network, I no longer think sidechains are useful (they are not at all useful for scaling, and additional features to mainchain, while desirable, are not necessary for the survival and continued usefulness of Bitcoin: offchain transactions, which just require n-of-n, are all you need in the future, and even a good number of features can be done with e.g. Smart Contracts Unchained, which is largely an offchain proposal, not a sidechain one). I am a coder, I write code, you can check my publicly-available code and see my coding style and compare it to the code of Zenon network (if you can find any).