Transactions and Segwit
I forgot a small but crucial detail. In order to be able to broadcast transactions using the 0.16.3 client on testnet, you need to add prematurewitness=1 to the config.file. (I've made an example 0.16.3 testnet client config file available as part of the alpha prerelease on https://github.com/gjhiggins/datacoin)

The reason for this requirement is that the alpha-release 0.16.3 client is configured by default to use segwit addresses src/wallet/wallet.h::Loc#112

Code:

enum OutputType : int
{
OUTPUT_TYPE_NONE,
OUTPUT_TYPE_LEGACY,
OUTPUT_TYPE_P2SH_SEGWIT,
OUTPUT_TYPE_BECH32,

OUTPUT_TYPE_DEFAULT = OUTPUT_TYPE_P2SH_SEGWIT
};

The broadcast/acceptance of segwit-address transactions is enabled by the prematurewitness assertion in the config.

Addresses in the client are the Dxxx ones familiar to users and this is configured via the config assertion addresstype=legacy. This latter assertion is local to one's client and can be trivially removed later, after an upgrade to segwit takes place.

Segwit and Bech32 addresses are a new feature of later varsions of Bitcoin Core. I recommend that when you import privkeys from 0.8 clients into the 0.16.3 client, you ensure that you provide a label, otherwise it can get a bit confusing because importing a legacy privkey results in three addresses appearing in the "Receiving addresses" list - the legacy address, the segwit address and the bech32 address.

You can check this out for yourself with the new makekeypair and listkeypair RPC/console call I've included. The results include the three addresses associated with the privey as well as the actual ECC private and public keys and, ofc the wallet privkey that you'll be familiar with. (Yes, they're all different, I recommend that you see for yourself.)

The aim of having the client default to segwit-enabled addresses is basically to enable the Datacoin chain to function in a pre-segwit state, pending a migration to segwit. The 0.16.3 client contains an activating protocol which enables a seamless soft-fork to segwit, as explained by Chicago:

Quote from: Chicago on April 18, 2020, 03:38:52 PM

The development agenda does include activating protocol which was never enabled for us during the upgrade from 0.8 to 0.16.

I've spoken briefly about it in the past.

We can simply build clients with updated chain parameters (in source) and require miners to eventually create blocks in the new format (the regular upgrade process we skipped which uses IsSuperMajority and BIP 9 deployment).

The activation protocol (technical name: "versionbits") is configurably sensitive to the proportion of blocks mined during a time-limited window (https://github.com/gjhiggins/datacoin/blob/bf9d6ae2a2c8ec27ca1ec0fac801f483e9f9db5e/src/chainparams.cpp#L118). If the proportion exceeds a given (configured) value during the window, the new protocol is permanently activated. Although the 0.16.3 client isn't yet configured to do this, if it were, then if the majority of miners were to use the 0.16.3 client, the chain would roll over to the new protocol and segwit would be permanently enabled for the Datacoin chain.

For the Bitcoin cloneparent, this activation mechanism has fulfilled its role, the Bitcoin blockchain successfully transitioned to segwit over three years ago (on August 24, 2017 at 2:57 AM). Subsequently, the redundant code implementing the activation protocol was removed from the Bitcoin codebase, being replaced by a simple variable assignment (https://github.com/bitcoin/bitcoin/blob/094402430925ec5aac6edbbf52d74f10c665da43/src/chainparams.cpp#L76). The effect of this change means that an upgrade of Datacoin to a more recent clone of Bitcoin (say 0.20) would necessitate a hard fork and all the disruption, organisational effort and risk of failure that would entail. That's why the current "upgrade" is to a fast-ageing 0.16.3 - once the Datacoin chain has soft-forked to segwit, a subsequent upgrade to a more recent clone of Bitcoin becomes far less onerous to arrange.

REST interface to stored data
One advantage of the 0.16.3 (and later) client is the addition of a REST interface. HTTP requests aimed at the standard RPC port of a host running the 0.16.3 client configured with rest=1 return results specific to the data included in the URL, e.g. http://localhost:11776/rest/tx/02d46971b8cba3fd1b3b4469f40676005dcb2313a24d13c36bb387a93b785bf6

The REST interface is not extensive as the somewhat self-explanatory code suggests:

Code:

uri_prefixes[] = {
{"/rest/tx/", rest_tx},
{"/rest/block/notxdetails/", rest_block_notxdetails},
{"/rest/block/", rest_block_extended},
{"/rest/chaininfo", rest_chaininfo},
{"/rest/mempool/info", rest_mempool_info},
{"/rest/mempool/contents", rest_mempool_contents},
{"/rest/headers/", rest_headers},
{"/rest/getutxos", rest_getutxos},

The implementation respects an "extension" protol, i.e. appending .hex to the above URL would return the transaction in hex and appending .json would return the results in the familiar JSON format.

I have extended the Datacoin REST interface with a txdata addition to the protocol which returns only the data of a data-storing transaction. In the designed primary use case, it accepts a .html extension - which is, of course, only meaningful for data stored as plaintext HTML (i.e. unlike the QDesktopServices "View locally", it does NOT handle gzipped/zipped stored HTML).

You can still use the GUI data storage facility directly to store binary data such as JPEGs and, because you will know the mimetype of what you stored, you can access the data via the REST interface by providing the appropriate extension.

So, if you are running the 0.16.3 client on testnet on the standard port (and configured with rest=1), the following URL will work in your browser: http://localhost:11776/rest/txdata/02d46971b8cba3fd1b3b4469f40676005dcb2313a24d13c36bb387a93b785bf6.html.

The difference between the "View locally" QDesktopServices approach and the REST approach is that the REST approach allows you to use Datacoin host txdata URLs to retrieve images instead of having to include them statically as base64-encoded strings.

i.e. the "hero" image inclusion tag in my blog post has chenged from:

Code:

to

Code:

(You can try the above in your browser, it'll show the hero image.)

It's slightly cheaper to store images as binary than it is to include them statically as base64-encoded, I found a net saving of 1 DTC over the "View locally" QDesktopServices approach.

Cheers

Graham