Thank You for your reply.
Line #468 (AcceptToMemoryPoolWorker) in validation.cpp refers and offers a solution:
Code:
// Reject transactions with witness before segregated witness activates (override with -prematurewitness)
Which temptingly suggests that if you include prematurewitness=1 in your conf file, or add -prematurewitness to the command line as indicated, senddata txs might well get broadcast. I don't know the effect of broadcasting segwit-enabled txs to a mixed network of 0.16 and 0.8 clients, it's possible that segwit txs will fail to validate on the 0.8 clients causing a fork across versions. You could set up a small local testnet of mixed-version clients and see what happens.
What I was trying to do with
Code:
addresstype=legacy
instead, was the opposite thing, i.e. sending a not-segwit tx from 0.16 client.
But your suggestion could work. I don't thing broadcasting segwit-enabled txs to a mixed network will cause a fork across versions.
In fact old clients see segwit txs as normal tx.
So the blockchain should not fork and maybe segwit txs could also be mined from old client.
BTW, it is a dangerous thing to do. We all don't want to risk a fork of Datacoin.
I already set up a mixed environment of 0.8 and 0.16 clients, because I had to solve an issue about not confirmed transactions.
The conclusion of this study was that clients version 0.16.3 ban clients 0.8.3 for Misbehaving.
When I sent a tx from my 0.8 client it does not appear in the getrawmempool command of my 0.16 client that is in the same LAN.
So I have this situation:
1) If I broadcast a tx from 0.8 client it is not propagated across 0.16 nodes in the network and so the transaction don't get confirmed for days
2) If I broadcast a tx from 0.16 client the tx is never broadcasted nor confirmed because it causes the error
Code:
CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet
and the wallet loses all its datacoins because it never receives from the network the tx of the unspent ones
Long story short, I ended with installing a 0.15 version and I deactivated all my 0.8 an 0.16 clients.
I also suspect that running different node versions from the same public IP will cause network issues, you could confirm this.
With 0.15 client I have solved my issue of unconfirmed txs.
This is a public node that should be reachable with
Code:
addnode=bytestamp.net:4777
Just to be clear, you reference the "0.16.3 client". Do you actually mean the 0.16.3 client (the one listed as "datacoin" in the Github list of repos, not the one listed as "datacoin-core") - I ask because as far as I can ascertain, everyone that's using the not-0.8 client is apparently using Verionum/Crossverse's version --- according to my server's response to getpeerinfo | grep subver
-cut-
I'm afraid that one does need to be precise in distinguishing which codebase is giving problems because the solutions will differ.
-cut-
I'm afraid that one does need to be precise in distinguishing which codebase is giving problems because the solutions will differ.
Yes, I mean the 0.16.3 client, i. e.
Code:
"subver" : "/Datoshi:0.16.3/"
But you can not see this node any more because, as said above, I deactived all my 0.16 and 0.8 nodes to solve the tx broadcasting issues.
From my getpeerinfo at moment, there are only 2 nodes ver 0.16, against 4 nodes ver 0.8 and 6 nodes 0.15.
But from what I understand, the 0.15 version is the unique that can broadcast txs to both 0.8 and 0.16 nodes (and 0.15, of course).
Now I am facing another issue.
Each day between 6:00 UTC and 7:00 UTC the blockchain slows down.
You can see this on the Datacoin block explorer selecting 3710777 as starting block.
You can see that block 3710775 was found after about 1 hour and an half since block 3710774:
Code:
3710776 f80e89a3777695a2d3c6f3130f2ae0cf38fa9e8b40009d94fa4696e9a18073ee 3420 2020-11-18 07:50:03 UTC
3710775 595b17b74e88a2f16cd43b9703aeb21edf1d226acba45bedf73eb52d7939985b 3421 2020-11-18 07:49:46 UTC
3710774 5dfa18492b4d5da41c43ccb735c2cc4c7b760d2c67ac6ee7ab4e50681da0f5c6 3422 2020-11-18 06:13:02 UTC
3710773 1438e6043ee77ac7be462b23b4b4b13067639775f5b7e51220d0e980e03af73d 3423 2020-11-18 06:11:20 UTC
You can also see it on coinsforall.io by clicking show more blocks.
This is happening every day.
Any idea?
Any one running Datacoin 16.3 and have a balance available - please send some DTC to dEnvzaRgyPtR2mZLPwTwN7LgpasN9rJ42H and post the amount and address here for a refund. Add your Datacoin 16.3 ip here to see if these clients want to speak to each other.