2020-01-24 to 2020-01-30
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
Obviously I set it to
After=bitcoind.service so that it
will start after Bitcoin Core was loaded.
file in the bitcoin/bitcoin
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
#! /bin/sh while ! bitcoin-cli "$@" getblockcount > /dev/null 2>&1 do sleep 1 done
SystemD invocations are not “normal” and you should
you pass into
bitcoind to the above script.
The above script then forwards it to
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.
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
if no unprocessed invoice is currently available.
I am still working on
multifundchannel, but for now I
connect have the ability to connect to multiple
nodes at once, to test out my
Later I will add
multifundchannel_cancel, I suppose.
Only a small amount of people asking about advice this week.
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.
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).