Quote from: gjhiggins on Today at 12:35:34 PM

Quote from: Chicago on Today at 02:31:11 AM

I don't think we need to go the scenic route here but its certainly a possibility we can entertain as well.

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

Thanks for all of those details, Graham.
Let me chew on this for a while and think about stuff.

Best Regards,
-Chicago