Renewed 03-03-2023

What problem are you experiencing? Are you not getting a successful compilation? Does it compile okay but won't run? Does it run but can't connect to client?

Cheers

Graham

No, segwit is not enabled for the Gapcoin chain, there's a handful of inveterate 0.9 holdouts - https://chainz.cryptoid.info/gap/#!network and we've been disinclined to force the issue (the Riecoin community seems rather more coherent). However, I take your point about the disproportionate negative impact of unnecessarily-duplicated effort. There is one unfortunate difference in the mining aspect, the "unreconstructed" GapMiner code still depends on the getwork RPC-API call and so that has to be re-implemented for each Gapcoin upgrade.

AIUI, 0.16 is the last Bitcoin version that enables versionbit "soft fork" upgrades, after 0.16 the segwit starting block height is hard-coded and (again AIUI) migrating to a more recent version would entail a hardfork - so that's why Gapcoin is frozen at 0.16. I did get an 0.20 version working but didn't take it to production. However, looking through the Riecoin release history it appears you folks successfully managed a hard fork from 16 to 20, which is encouraging.

I have some ideas that I'm working on with respect to mapping the blockchain into RDF (e.g. https://github.com/gapcoin-project/gapcoin-core/blob/6828bdebf2f07367799e41b04e081de24e322057/src/rpc/blockchain.cpp#L2186) and I'm doing some groundwork atm.

Cheers,

Graham

Apologies for the delay in my responding to your kind words and positive suggestions.

Do you feel that it's worth the effort?

It's difficult to express this without a sense of sounding whiny ... I have spent some time thinking about this in depth but I just can't convince myself that there is sufficient residual interest in the Datacoin chain to justify the amount of effort required for a migration. There isn't even enough interest to protect the chain against the current exploitation by just one individual of the emissions rate/difficulty modifier relationship.

Although I see myself as merely an occasional technical contributor, I can see why public perception may prefer a caretaker interpretation. However, even as an erstwhile curator, the main issue is that there's very little left to curate. The community seems to have evaporated leaving a few isolated individuals remaining. Communication ranges from terse to non-existent. Both the mining pool and exchange listing persist via the goodwill of the operators towards a 2013-vintage altcoin.

I have to confess that I'm struggling for an answer to the question - What's the point of continuing to support the remnants of a community that don't appear to want support?

Cheers

Graham

Indeed there was a problem, as advised on 2021-06-16 in this post ...



Cheers

Graham

My server reports pretty much everything as incoming, I get a better idea by running a client at home, anything that shows up in the Peers tab is a listening node.

If your client is hosted on your home network, it likely won't be accessible externally unless your router supports NAT/UPNP and you have configured the router to enable UPNP for the machine running the client.

Belt and braces - have upnp=1 in the config (or rather ensure that you don't have upnp=0 in the config - which you don't seem to have).

Cheers

Graham

Datacoin reports #2

A slight reduction in the number of active Datacoin nodes (as visible from my Hetzner-hosted node on 144.76.118.44) but healthy enough for the moment:

address:port	client version	listening
83.161.158.205:59129	Satoshi:0.8.3	no
89.73.143.76:58258	Satoshi:0.8.5	yes
95.217.78.168:60992	Satoshi:0.8.5	yes
[2a01:4f9:4a:1e17::2]:36688	Satoshi:0.8.5	no
85.19.25.38:27551	Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)	no
213.31.19.87:64089	Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gunk-beta)	no
40.87.106.229:63764	DatacoinCore.Veter:0.15.99.8	no
140.186.218.230:51153	DatacoinCore.Veter:0.15.99.8	no
31.131.65.221:58060	DatacoinCore.Veter:0.15.99.8	no
51.148.146.204:54912	DatacoinCore.Veter:0.15.99.8	yes
140.186.218.230:52004	DatacoinCore.Veter:0.15.99.8	no
45.33.238.99:56899	Datoshi:0.16.3	yes
188.217.252.184:56475	Datoshi:0.16.3	no
185.62.96.74:59113	Datoshi:0.16.3	no
109.168.57.185:5748	Datoshi:0.16.3	no
94.63.199.33:54315	Datoshi:0.16.3	yes
[2001:818:e30e:d300:e5fe:883c:4268:808d]:55037	Datoshi:0.16.3	no
144.76.118.44:4777	Datoshi:0.16.3	yes

An "addnode list" and a description of the significance of "listening" are available upthread: #msg57299213

Cheers

Graham

addnode=144.76.118.41
addnode=91.121.221.92


Cheers

Graham

It's getnetworkhashps but it's only in the 0.16.3 client (don't use it for txs) and was transcribed from the corresponding code in the unreleased Primecoin branch "primecoin-0.16.3". Its accuracy in terms of representing hashpower is questionable but its representation of relative variation should be a bit more reliable. I don't know why CrossVerse didn't include it in the 0.15.99 code, maybe it's profoundly unreliable.

You are correct in your observation that it is based on an inference: “The hashrate can be calculated from the expected rate of finding a block (1440 a day), the actual rate of finding a block and the current difficulty”.

I reworked the plot in my own client to show a full week's worth (10080 blocks), the plot shows that difficulty is still adjusting to the new network hash rate:



Cheers

Graham

Datacoin reports #2


The delay you observed is a direct result of the collapse of networkhashpersec.

The reduced number of pool workers is likely related to the issue of coins stuck on segwit addresses.

GPU hashpower pretty much overwhelms CPU hashpower, very few blocks are mined with CPU so when GPU miners have been throwing hashpower at the chain and then suddenly stop, there is a huge drop in network hash and it takes time for the difficulty to adjust. During this period it is, ahem, difficult to mine a block, so the emissions rate plummets and blocks become few and far between.



Cheers

Graham

Datacoin reports #1

A more encouraging current state of the Datacoin network (as visible from my Hetzner-hosted node on 144.76.118.44):

address:port	client version	listening*
83.161.158.205:55755	Satoshi:0.8.3	no
[2a01:4f9:4a:1e17::2]:42938	Satoshi:0.8.5	no
95.217.78.168:4777	Satoshi:0.8.5	yes (DE)
89.73.143.76:4777	Satoshi:0.8.5	yes (graymines.net PL)
85.19.25.38:8800	Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)	no
113.110.231.187:4777	Satoshi:0.8.6	yes (CN)
213.31.19.87:61690	Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gunk-beta)	no
213.31.19.87:59265	Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gunk-beta)	no
51.148.146.204:4777	DatacoinCore.Veter:0.15.99.8	yes (gjhiggins, NAT/UK)
51.148.146.204:37578	DatacoinCore.Veter:0.15.99.8	no (gjhiggins)
140.186.218.230:51126	DatacoinCore.Veter:0.15.99.8	no
31.131.65.221:49317	DatacoinCore.Veter:0.15.99.8	no
40.87.106.229:49428	DatacoinCore.Veter:0.15.99.8	no
140.186.218.230:49353	DatacoinCore.Veter:0.15.99.8	no
185.62.96.103:53475	Datoshi:0.16.3	no
51.148.146.204:48776	Datoshi:0.16.3	no (gjhiggins)
45.33.238.99:4777	Datoshi:0.16.3	yes (bytestamp.net, IT)
109.168.57.185:4394	Datoshi:0.16.3	no
94.63.199.33:4777	Datoshi:0.16.3	yes (PT)
144.76.118.44:4777	Datoshi:0.16.3	yes (gjhiggins, UK hosted DE)
[2001:818:e30e:d300:f914:db7c:a75:78f5]:59620	Datoshi:0.16.3	no

*"listening" nodes are clients configured with listen=1, they can be synced from and they broadcast transactions.

For convenience, I have separated out those clients which are currently listening:

The client expects listening nodes to use the default port of 4777 so specifying the port is unnecessary - except in the rare case where a listening client has been configured to use a non-standard port and so it isn't discovered by default and its presence needs to be advertised here and it has to be specially added to datacoin.conf as addnode=<ipaddress>:<port>.

In general, a client connecting via a port other than 4777 is not listening and should not be included as an addnode because it is pointless and possibly misleading to do so.

Cheers

Graham

Uh-huh, networkhashrate has collapsed.

in slightly more positive news, I recovered CrossVerse's "madpool" addition, after finally figuring out what it was all about.

It adds a pool server to the client and disables in-wallet mining, allowing the client to act as a local pool server to a local xpmclient GPU mining pool client.

I'm maintaining the code in a separate branch of the 0.16.3 called "poolserver" - in which in-wallet mining has been removed and replaced by the pool server which is started automatically on client startup.

It seems to work okay but it's difficult to be confident while the network is in its current state of disarray. I'll release the code once I'm confident that it actually works.

Serving:
The in-client pool server is configured by two additional options to add to datacoin.conf or the command-line, the default settings are shown below:

Mining:
xpmclient binaries for nVidia and AMD are available from the Primecoin repos release 10.5.beta1

The xpmminer config.txt configuration file uses the frontport value as "port", IP address is 127.0.0.1, replace the default Primecoin address with a (legacy) Datacoin address:

One favourable implication of this is that it might open the way for a soft-fork migration to segwit.

Cheers

Graham

I have been investigating: https://github.com/gjhiggins/xpmminer/commits/datacoin

Looks like I'm probably wrong about the details of the block construction issue (i.e. the significance of the Datacoin-specific txdata tx field) - getblocktemplate would seem to accrue all the txdata into a single block of hex for the miner to use.

An example from testnet:


Cheers

Graham

That does recover the coins from the unbroadcast tx. But that doesn't change the reason for the tx being rejected (segwit tx on a non-segwit chain) so any coins currently owned by a Datacoin address beginning with 'd' (as opposed to 'D') are effectively now unspendable.

Cheers

Graham

PM me for a refund.

Cheers

Graham

As far as my experience goes, pace that the client is properly configured in src/wallet/wallet.h with OUTPUT_TYPE_DEFAULT = OUTPUT_TYPE_LEGACY (and not the Bitcoin-specific OUTPUT_TYPE_DEFAULT = OUTPUT_TYPE_P2SH_SEGWIT, sigh) or that users infallibly have addresstype=legacy in the datacoin.conf and refrain from using segwit/bech32 addresses (perhaps too much to expect), then the 0.16.3 client (based on CrossVerse's 0.15.99 version) works with a network that it shares with 0.8.6 clients.

TBF, I did report on the OUTPUT_TYPE_DEFAULT issue and there has been some discussion of the broadcast of segwit-enabled txs some time ago but working with a mixed network of differently-capable clients is taxing on users, some of which need help at the level of "How do I dump a privkey?".

The 0.16.3 client is the last of the Bitcoin versions to have versionbits support for soft-fork migration to a segwit-enabled network, later versions are hard-coded on the (for Bitcoin, certain) assumption of a segwit-enabled network. A versionbits-controlled migration is probably the most desirable option in terms of enabling the community members to migrate in their own time but an abrupt hard fork to a segwit-enabled network that excludes 0.8.6 clients is also, ofc, feasible if backed with enough CPU/GPU power.

Fedde of Freiexchange is in position to switch to an 0.16.3 Datacoin client when a production-quality version becomes available.

But one of the more problematic issues in a versionbits soft migration to an 0.16 segwit-enabled network is that the only remaining mining pool (graymines.net) is stuck on 0.8.6 and is unable to use versionbits to signal segwit acceptance. In a PM, Graymines pool operator MarcusDe informed me of the difficulties of integrating an upgraded client into the “old as hell” (as he describes it) pool code, which is not wallet_code <-RPC-> pool_code but is integrated with the wallet client as a Windows binary - “Last time it was years ago when I made something there, so well, it will take long time.”

I just checked https://dtc.graymines.net/index.php?id=blocks to discover that the pool has 8 workers and mined 197 out of the last 200 Datacoin blocks. So, unless Datacoin users successfully collectively agree to cease pool mining or MarcusDe can be persuaded to shut the pool, a versionbits-controlled soft fork to a segwit-enabled network looks to be off the cards.

If the pool is shut down, the outcome will leave Datacoin network mining as CPU-only and that only via the wallet's built-in miner ...

fwiw, there is a candidate Primecoin solo miner with a combined CPU/GPU implementation - https://github.com/primecoin/xpmminer but, due to the fact that the structure of Datacoin transactions differs from that of Primecoin transactions (Datacoin transaction have an additional txdata field), the Primecoin solo miner is incompatible with Datacoin mining. The issue lies in the fact that the solo miner constructs its own blocks to hash, based on the JSON content returned by the getblocktemplate RPC call. This block construction must be adjusted so that Datacoin-compatible blocks are generated - currently, they aren't and all of the Datacoin clients (0.86, 0.15.99, 0.16.3) reject the blocks submitted by the miner.


Cheers

Graham

Cheers

Graham

Turns out that the wallet is hard-coded by default to use segwit addresses and on a non-upgraded network, coins sent to segwit addresses are lost.

Don't use the 0.16.3 client, revert to either the 0.8.6 client or the Crossverse 0.15.99 client.

I've withdrawn the 0.16.3 release and deleted the repository as it's clear that supporting this particular upgrade is beyond my skillset.

If you have coins stuck on segwit addresses, PM me with the relevant 0.16.3 client privkey and I'll replace your coins.

Sad but true.

Cheers

Graham

Latest list of recently-seen nodes, edited from bytestamp's peers list

addnode=102.165.224.64
addnode=103.246.152.226
addnode=103.246.152.233
addnode=112.198.79.59
addnode=112.95.235.238
addnode=113.10.158.207
addnode=113.10.242.157
addnode=114.79.37.60
addnode=117.34.72.3
addnode=122.192.218.102
addnode=144.76.118.44
addnode=144.76.64.49
addnode=146.199.233.66
addnode=150.143.250.57
addnode=175.139.175.82
addnode=192.186.4.213
addnode=202.114.29.51
addnode=204.48.92.37
addnode=204.48.92.48
addnode=213.31.19.33
addnode=213.31.19.87
addnode=213.31.19.98
addnode=218.57.139.132
addnode=221.194.44.178
addnode=221.194.44.198
addnode=221.194.44.205
addnode=27.145.61.18
addnode=45.63.115.238
addnode=50.17.6.175
addnode=51.148.146.204
addnode=54.193.18.89
addnode=54.193.64.123
addnode=54.206.54.159
addnode=58.218.199.216
addnode=58.218.199.248
addnode=89.73.143.76
addnode=91.250.62.26
addnode=95.217.78.168
addnode=graymines.net



Edit:
Meh, I fed them into my client, which can only connect to:

addnode=144.76.64.49
addnode=51.148.146.204
addnode=91.250.62.26

So yeah, there were only two listening nodes, now three - and two of them are my nodes, one remote, one local (configured with `upnp=1` so my router's UPNP allows external access to the standard 4777 port - but a static IP address is needed, won't work with network running behind a dynamic IP address).


Cheers

Graham

Meh, wrong. Just tried to synch from 213.31.19.87 and 89.73.143.76,  can't connect to either from here.

Currently, the only listening nodes are:
It's worth ensuring you have both as addnodes, if not connects.

Cheers

Graham