Proofgold Core 0.2.7

by BlakeKeiller, Sunday, November 07, 2021, 10:19 (28 days ago)

Proofgold Core 0.2.7 is ready:

https://proofgold.org/proofgold-core-0.2.7.tgz

The main reason to release a new version was to remove any remaining dependence on the proofgold.org domain name. Already in 0.2.6 the private messaging and ability to anonymously post on the forum were removed. (This has the side effect that no one new can join this discussion forum, so I now consider the forum defunct and only a way to make announcements like this. If someone who has already joined the forum creates a new forum, please feel free to post a link to it while proofgold.org is still online.)

To prepare for the next era of Proofgold in which there is no "central" source of information like proofgold.org, "alerts" have been added. An "alert" is a special kind of litecoin transaction that contains data. There are four kinds of alerts:

. Alert : This is just a text message of < 70 characters. The message is placed in the debug.log file of all users. It is also printed to stdout if the process is not running as a daemon. Any user can publish an alert using the "broadcastalert" Proofgold command.

. Listener : This is an ip address (with port) or onion address (with port) for a Proofgold node listening for connections. This is to help new nodes join the network and an alternative to the old method of looking up peers at proofgold.org/peers.txt. If your node is listening at a given onion or ip address, you can publish this as an alert using "broadcastlistener." New nodes will see these alerts and try to connect to your node (or at least save the url for future tries).

. Bootstrap : This is a URL for a bootstrap (to easily initialize the database without needing to sync from the beginning). Previously bootstraps were always available from proofgold.org/bootstrap, though there was the ability to configure "bootstrapurl" to be another value. Now "bootstrapurl" defaults to the empty string. Users can give their own bootstrapurl by setting "bootstrapurl=..." in proofgold.conf or giving "-bootstrapurl=..." on the command line. This is only relevant the first time a node is started and there is no database. If no bootstrapurl is given, then the new node starts by searching recent ltc blocks for broadcasts of a Bootstrap Alert giving a url to use. The Proofgold command "broadcastbootstrap" to create a Bootstrap Alert.

. Bootstrap Warning : This is an alert warning nodes not to use a given bootstrap url. This could be because a bootstrap url is out of date, has disappeared, or was corrupted in some way. When a new node starts, it ignores any Bootstrap Alert that was followed by a Bootstrap Warning Alert. The Proofgold command "broadcastbootstrapwarning" can be used to create a Bootstrap Warning Alert.

For users who want to create and supply their own bootstraps, I'm releasing a very small bash script for doing this:

https://proofgold.org/makebootstrap

You will likely need to change some absolute pathnames to use it. The script currently assumes the .proofgold directory is in the home directory of user "pfg." It also assumes Apache is serving the web site given by the ip address using the data in /var/www/html.

A few other changes are worth noting.

The networking code has been reworked so that connections can declare the "strength" of connection they desire when connecting to a listener. (The idea is that if a node has no connection, it urgently wants one -- requesting a "strong" connection. The more connections the node has, the less urgently it wants one.) In case a listening node is full of connections and a new node wants a connection more urgently, the listening node will drop the weakest connection to make room for the new one. In case of a tie, the new node had the option of doing some proof of work to override the old node.

Nodes die quite often and I did work to localize the most common reason. It seems to happen (mostly) when "flush sout" is called in send_msg_real in net.ml. My guess is that the channel has closed and so the call to flush causes a problem. From my reading flush should NOT have this effect, but nevertheless it seems to. I tried various fixes without success, so unfortunately your nodes will die regularly and you will need to manually restart them. IF SOMEONE KNOWS HOW TO FIX THIS PLEASE LET ME KNOW.

There is also a new database module type that exposes a new function "dbbincp" that directly copies the binary value being stored into a string buffer. This is only used for DbBlockdelta, but might make sense for other Db's. In the case of deltas in particular, it was clear that when a block delta is requested by a peer, time is wasted deserializing the data from the database and then reserializing it to send to the peer. Now the binary data is sent directly.