Quote from: sampei7777 on Today at 02:59:17 PM

That said, if you search on bytestamp (https://www2.bytestamp.net/blocks/qutx) for the transaction id

8b077e4eb862f7ee11ee14f2052430ad1f82b1831ec8b57f652c5cd35932fd88

you can see that there is no such tx in the blockchain.

This may suggests that your transaction was never broadcasted to blockchain. You can see this with the command getrawmempool.

That is what is implied by the “0/unconfirmed” status. The 0 is "nodes to which this tx has been broadcast". I've had this happen - in the 0.16.3 client there's an option "Abandon Transaction" in the Transactions tab pop-up dialog. I've found that I needed to -rescan -zapwallettxes=2 in order to clear these failed txes from the wallet. In principle, if they're in the mempool, they will likely get sent eventually. Bitcoin 0.16.3 has a fee-replacement scheme that you can use to bump up the fee to that it is more attractive to miners - but that's a feature of the Bitcoin network and unlikely to be of much use in a Datacoin context.

Quote from: sampei7777 on Today at 02:59:17 PM

But... if you go to

https://dtc.graymines.net/index.php?id=blocks

you can see that block # 3873054 was found by the address:

dc1q94pvtll03nsfrgn9felgtnzv98836huzk2nddp

That is not a legacy address but a segwit one.

So? Have we switched to Segwit?

Grahams?

No, it's possible that someone who isn't familiar with the new extended keys doesn't know to use addresstype=legacy in the config file.

dig dtc.graymines.net resolves to 89.73.143.76 - which is reported by getpeerinfo to be “/Satoshi:0.8.5/”. I have just checked an 0.8.6 client (after some struggles to get it to compile under Ubuntu 0.18, see below) and it reports that address as invalid, so I doubt that graymines was able to send that reward.

Not sure what's happening with the network, my remote server reports the following clients seen atm:

Quote

123.125.148.46:4777 - /Satoshi:0.8.3/ 102.165.224.64:61137 - /Satoshi:0.8.3/ 89.73.143.76:4777 - /Satoshi:0.8.5/ 95.217.78.168:35254 - /Satoshi:0.8.5/ [2a01:4f9:4a:1e17::2]:46230 - /Satoshi:0.8.5/ 85.19.25.38:6390 - /Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/ 150.143.207.111:53560 - /Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gunk-beta)/ 140.186.218.230:50890 - /DatacoinCore.Veter:0.15.99.8/ 40.87.106.229:62839 - /DatacoinCore.Veter:0.15.99.8/ 31.131.65.221:60853 - /DatacoinCore.Veter:0.15.99.8/ 150.143.207.111:61269 - /DatacoinCore.Veter:0.15.99.8/ 45.33.238.99:33943 - /Datoshi:0.16.3/ 108.160.136.247:51398 - /Datoshi:0.16.3/ 79.114.44.38:49627 - /Datoshi:0.16.3/ 51.148.146.204:56982 - /Datoshi:0.16.3/ 51.148.146.204:59944 - /Datoshi:0.16.3/ 51.148.146.204:34232 - /Datoshi:0.16.3/ 51.148.146.204:34234 - /Datoshi:0.16.3/ 45.63.115.238 - ""

As regards switching to segwit ...

Given that the 0.16.3 client retains the versionbits code required to effect the transition via soft-fork, one possible roadmap to segwit is:

1. After a majority of users have upgraded to the 0.16.3 client ...
2. At some widely-advertised point, the versionbits code is enabled to create a specific window of time
3. Users then download and use the new versionbits-enabled client, signalling their willingness to accept the change to segwit
4. When the window of time expires, assuming the majority of users are using the versionbits-enabled client, the change becomes permanent.
5. At some widely-advertised point, the block and transaction versions are bumped, excluding the old clients from the network
6. A majority of users update to this new client.

As far as I can tell, atm there are three Datoshi 0.16.3 client operating (other than the ones I’m running on 51.148.146.204), one somewhere on rdsnet.ro, one on digisoftsrl.it and one on vultr.com and as I haven't actually released the 0.16.3 client (I'm still trying to ensure it is working as expected), any progress towards a network upgrade is likely to be leisurely at best.

Although the existing compiled binaries of the 0.8 clients remain functional, the 0.8 sources are increasingly falling out of scope. They no longer compile successfully with the systems packages of contemporary OS distros, requiring some configuration acrobatics to compile with self-built legacy libraries for openssl and boost.

Cheers

Graham