[ANN] Datacoin - Censorship-Free Data Storage

[hamburger]

Hi DataSea,

I appreciate the assistance, however the transaction did not came through on my side.

On this address I made a payment from the address to the same address and it would not go into the local mem pool nor did it enter any of the nodes connected to the client.

This address are now imported into  the 0.15.9.08 version and it show the payment to it self with all the confirmation sine the 6th of July 2020 -  the 0.16.3 client do not see the transactions on the block chain.

I'll have a look at the previous posts to see if any one mention a possible problem or maybe Graham will be able to tell us.

Anyway, just right click on the transaction, select abandon and the coin will appear in your wallet again.

Thanks,

H

Hi Hamburger,

2.2 DTC to your addy

Date: 8/10/2020 05:09
To: dEnvzaRgyPtR2mZLPwTwN7LgpasN9rJ42H
Debit: -2.20000000 DTC
Transaction fee: -0.05000000 DTC
Net amount: -2.25000000 DTC
Transaction ID: 05943dd758a5181c30add2981ac8f76fbb91eafab9fa3b03ff7e81706fbc5552

using
Datacoin Core version v0.16.3.0-74075b1f3-dirty (64-bit)

Let me know how I can be of greater assistance!

Kind Regards,
DataSea

[1713514857]

1713514857

[1713514857]

1713514857

[hamburger]

Hi,

New development!

After importing the address generated on the 0.16.3 client into the 15.99.8 client, I now have another column in the Balances section "Watch-only"



Are there anyone that can tell me the story behind this?

Thank you,

H

[minerja]

Good morning,
I'm midway thru sorting out all my crypto drives, and so far i believe i have found 8 different versions of Datacoin (for windows).
I was just wondering which wallet most people are using.
When i say 8 versions, i have found 3 versions of Datacoin HP14, which initially i thought were all the same, but on close inspection, the files sizes / dates are different, and 1 version has 1 extra .dll

I cannot remember where i got each version from, and i think there was a "virus" scare with at least 1 of them.
That got me to looking at the explorer, which i seem to remember had version info, but i cannot find ANY working explorers currently.
Then i went to page 1 of this forum,

Official Github Repository
https://github.com/datacoinproject/datacoin (version 0.16.3)

Datacoin Core 0.15.99
Windows wallet:  https://yadi.sk/d/eu7rJ9EN3VSYBF

0.8.6 Wallet (Binary) Releases
for Windows, Mac and Linux
https://github.com/datacoinproject/datacoin/releases

Website
www.datacoininfo.org - which takes you to "http://datacoininfo.org/Wallets/datacoin-qt.exe" (no version, you have to just try it)

So all in, its a right confusing mess, no wonder the newbies get stumped.

If any one can find stats as to which wallet the majority are using, i'd like to make sure i'm at least using that one.
I'm not sure why the "https://chainz.cryptoid.info/" explorerer is no longer available, but that is my 2nd concern. With the extremely low hashrate currently, without a live block explorer, it is virtually impossible to know if the chain has split, and whilst that might be fine using coinsforall.io, if you are solomining, its a nightmare.

As a starting point, the most common wallet i have on my Windows and Linux PC's is version 0.8.6.

Any thoughts?

[sampei7777]

Hi all,

Does anybody know why my transactions don't get confirmed?

https://www2.bytestamp.net/docs/qdoc/en/73722aaef2be689dff1c327261968c65

Transaction

615a2825d6442d4584541186a747b6f3087bebc2f72c885f4b10ced1f134a565


Thank You

[extro1]

I will schedule a Zoom meeting for Datacoin, 1pm EST Friday 4th September.  I will post the Zoom link here, on Twitter and on Telegram.

[sampei7777]

Hello,

Good morning,
I'm midway thru sorting out all my crypto drives, and so far i believe i have found 8 different versions of Datacoin (for windows).
I was just wondering which wallet most people are using.

-cut-

So all in, its a right confusing mess, no wonder the newbies get stumped.

If any one can find stats as to which wallet the majority are using, i'd like to make sure i'm at least using that one.
I'm not sure why the "https://chainz.cryptoid.info/" explorerer is no longer available, but that is my 2nd concern. With the extremely low hashrate currently, without a live block explorer, it is virtually impossible to know if the chain has split, and whilst that might be fine using coinsforall.io, if you are solomining, its a nightmare.

As a starting point, the most common wallet i have on my Windows and Linux PC's is version 0.8.6.

Any thoughts?

well, ByteStamp is a live Datacoin block explorer and it has been online since September 2014. 

You can see it here:

https://www2.bytestamp.net/blocks/index

Or, on the new website, here:

https://www.bytestamp.net/timestamp-status-overview-and-archive/

then select a date and the "blockchain" radius button.

About Datacoin client, I (ByteStamp) have both Datcoin core 0.16.3 and 0.8.3.

This is a list of known peers  at moment (with version)

Code:

 bytestamp.net : Datoshi:0.16.3
 
 151.80.96.105 (coinsforall.io) :  Satoshi:0.8.3

45.63.115.238 (datacoin.tk) :  version  is empty  ???
 
 95.217.78.168 :  Satoshi:0.8.5

102.165.224.64 : Satoshi:0.8.3

146.198.18.51 : Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0)

146.198.18.51 : Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gFormat:h-beta)

185.220.101.213 : Datoshi:0.16.3

77.247.181.162 :  Datoshi:0.16.3

51.75.144.43 :  Datoshi:0.16.3

That said, I also noticed that some transactions can take up to 1 or 2 days to be confirmed.

What I saw by experimenting is that clients version  0.16.3 ban clients 0.8.3 for Misbehaving.

So I guess that if a transaction is created from a 0.8.3 client it is not broadcasted to the network when it reaches a 0.16.3 node.

But I had unconfirmed transactions both from 0.8.3 and from 0.16.3 client 

I think this is normal, because if my transaction is confirmed in a block that then is orphanized, it takes more time to be confirmed.

If you go here:

https://www2.bytestamp.net/docs/new/en/MjAyMC0wOC0zMCAxNDozMToxOSBVVEM=%0A


you can see that transaction

5c4e1e1ba1e06529319b654f0cb7e1dfbb136fe055906bdbb66856cef57c48d8

was confirmed after the transaction

 5dd9b3c78eb8ae56e6e0fb691ca2d6d64ba714c1b708b654c2c39674106e07f6
 
 even it was sent before.
 
 So, I don't think the blockchain has split, because you can see in the explorer that each block has the previousblockhash of the previous block.
 
 You can easily see it here:
 
 https://www2.bytestamp.net/c/block
 
 than select "DTC" on the left instead of BTC and click submit  leaving the field empty.
 
 But, all that unconfirmed transaction mean that there are a lot of orphaned blocks.
 
 This is normal due to the decentralized nature of blockchain.
 
Maybe if a block is found by a 0.8.x node, than it is not broadcasted to the network when  it reaches a 0.16.3 node and than it is orphanized in some way.

 BTW, I am analyzing the situation and any help is appreciated.

[extro1]

You are invited to a scheduled Zoom meeting.

Topic: Datacoin
Time: Sep 4, 2020 01:00 PM EST

Join Zoom Meeting
https://us02web.zoom.us/j/86754884972?pwd=OXlPQk9hZnkvUWlGdStUcGU2YlJjUT09

Meeting ID: 867 5488 4972
Passcode: 249801
One tap mobile
+16465588656,,86754884972#,,,,,,0#,,249801# US (New York)
+16699009128,,86754884972#,,,,,,0#,,249801# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 9128 US (San Jose)
        +1 253 215 8782 US (Tacoma)
        +1 301 715 8592 US (Germantown)
        +1 312 626 6799 US (Chicago)
        +1 346 248 7799 US (Houston)
Meeting ID: 867 5488 4972
Passcode: 249801
Find your local number: https://us02web.zoom.us/u/kcNnqaVJtC

[extro1]

Hi All.  The meeting went very well.  Unfortunately due to proprietary concerns from some of the participants it was not possible to record the meeting.  Three ideas stood out:  1.  One of the participants will arrange for all versions of the client to be active on the cloud.  2.  A second participant will be translating the Bytestamp software into javascript to upload onto the Datacoin blockchain (which will now be run from the cloud).  I myself will continue to maintain the Datacoin shop and MLM, currently under maintenance.

The next Datacoin Zoom Meeting is on Friday, 18 September.

-extro

[extro1]

You are invited to a scheduled Zoom meeting.

Topic: Datacoin
Time: Sep 18, 2020 01:00 PM Eastern Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/81655511377?pwd=ZkJIL08yRlo0NlFpSUtRN0pWVCtoZz09

Meeting ID: 816 5551 1377
Passcode: 465617
One tap mobile
+16699009128,,81655511377#,,,,,,0#,,465617# US (San Jose)
+12532158782,,81655511377#,,,,,,0#,,465617# US (Tacoma)

Dial by your location
        +1 669 900 9128 US (San Jose)
        +1 253 215 8782 US (Tacoma)
        +1 301 715 8592 US (Germantown)
        +1 312 626 6799 US (Chicago)
        +1 346 248 7799 US (Houston)
        +1 646 558 8656 US (New York)
Meeting ID: 816 5551 1377
Passcode: 465617
Find your local number: https://us02web.zoom.us/u/kdWpy1hhlp

[gavrilo77]

What is the last GPU miner for DTC?

Anyone have bootstrap?

[gjhiggins]

What is the last GPU miner for DTC?

Anyone have bootstrap?

1. AFAIK, https://github.com/madMAx43v3r/xpmclient

2. Sort of, (a gzipped tar of blocks/ and chainstate/) but it weighs in at 2.3Gb.

However, in my recent experience, a fresh client takes only 3-4 hours to sync from 0. I have a running node on the open subnet, use addnode=144.76.118.44.

Cheers

Graham
 

[MrBudgens]

https://www.coindesk.com/filecoin-mainnet-now-live

I saw the news that Filecoin finally launched, and it made me remember the datacoin project. I'm glad to see it's still alive, but it seems to have been rather quiet in recent years. Is it still under active development? It's hard to tell if this is the main discussion forum anymore. Also, now that there are (at least) Filecoin, Storj/Tardigrade, Siacoin and MaidSafe competing in or near the crypto space, how will datacoin carve out its own niche?

[sampei7777]

Hi all,

I think there is an issue with 0.16.3 client.

If I send DTCs to this client it receive them.

But if I use this DTC on this 0.16.3 client to do a transaction, the tx is never  broadcasted and the balance is zeroed.

This happens when using the senddata method of Datacoin.

This issued is caused by SegWit feature of 0.16.3 clients

In my debug.log I can see the trasaction whit this:

Code:

CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet

Now, no-witness-yet is  a message produced when you try to send a segwit spend but the blockchain hasn't activated segwit yet.

And I think Datacoin blockchain hasn't activated segwit yet.

I also tried to put

Code:

 addresstype=legacy

 
 in conf, but with no luck.
 
 It always wants to do a segwit transaction.
 
 I guess this is related to the senddata method, that is a Datacoin method (not a Bitcoin one)
 
 So maybe the directive
 

Code:

 addresstype=legacy

 
  cannot control how senddata method works.
 
  So, can anyone test if senddata method works on 0.16.3 client?
 
  I would like to know if it is a my own issue of if it is a client issue.
 
  Any help is appreciated.
 
  Thank You.

[gjhiggins]

Code:

CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet

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.

And I think Datacoin blockchain hasn't activated segwit yet.

Indeed it hasn't.

Line #106 of chainparams.cpp refers:

Code:

consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 999999999999ULL; //DATACOIN SEGWIT oтключaeм SEGWIT = 1479168000; // November 15th, 2016.

where "nStartTime = 999999999999ULL" means "sometime in the distant future" (and oтключaeм apparently translates to "turn off")

HTH

Cheers

Graham

[waya]

Hello All,

I have to say I love this coin.  The thought of storing uncensored information on a blockchain is a great concept.  In today's world of microaggressions and political correctness, it is refreshing and welcome when I see anything that is censorship-free.  Whatever happened to the freedom to communicate and think for yourself.  I will be using this to save pictures I take of materials for my businesses.

Cheers,
Waya

[gjhiggins]

I think there is an issue with 0.16.3 client.

Just to be clear, you reference the "0.16.3 client". 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

Code:

    "subver": "/Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",

[gjhiggins]

I think there is an issue with 0.16.3 client.

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

Code:

    "subver": "/Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",

The Veronium/Crossverse client version string is:

Code:

const std::string CLIENT_NAME("DatacoinCore.Veter");

The 0.16.3 client version string is:

Code:

const std::string CLIENT_NAME("Datoshi");

And the addresstype option was added to upstream Bitcoin after Veronium cloned the codebase (he cloned it when it was 0.15.99, well before the 0.16 version was released). It is present in the 0.16.3 version but as far as I'm aware, no-one's using that implementation.

I'm afraid that one does need to be precise in distinguishing which codebase is giving problems because the solutions will differ.

Cheers

Graham

[sampei7777]

Hello,

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.

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?

[gjhiggins]

Thank You for your reply.
...
Now I am facing another issue. Each day between 6:00 UTC and 7:00 UTC the blockchain slows down.

This is part one of a two-part response.

Providing even limited support via bitcointalk is both time-consuming and awkward, so I've set up a Datacoin Discord server for this express purpose, here's the invitation https://discord.gg/evxVsb5FXB. I'm usually online mid-morning to late at night GMT if anyone wants specific help or advice.

fwiw, I'm working on the Datacoin 0.16.3 reference client at the moment so I'm interested in how these issues may be resolved.

Cheers

Graham

[gjhiggins]

This is the second part of the response

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.

Thank you, the pointer to "old clients see segwit txs as normal tx" was most useful. The key fact is contained in the post following the one you linked to:

old clients will not receive transactions in the segwit transaction format. Segwit transactions will only be sent in response to a getdata for inv type MSG_WITNESS_TX. However old nodes will not have that inv type in their getdata messages, only MSG_TX, which indicates to segwit capable nodes to send the transaction in the legacy format.

That clears things up a lot and bodes well for the future.

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.

I'll have a look at this. I do know (from working on a Gapcoin 0.16.3 reference client) that this isn't the case for a mixed network of 0.9/0.16.3 nodes but I haven't checked with a mixed network of 0.8/0.16 nodes, the situation may differ.

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.

Given that experience, I can understand why. But there may be some other factor causing the problem - I've just successfully received some DTC from freiexchange with my 0.16.3 client (assuming that freiexchange are using an 0.8 client which may not be the case). After some "fettling", I now have a compiled 0.15.99 Crossverse reference client and am working to get the (rather elderly) 0.8 client to compile on my Mint/Ubuntu 0.20 laptop. Then I can replicate your experiment and maybe have a chance to see where things go astray.

I also suspect that running different node versions from the same public IP will cause network issues, you could confirm this.

No, that should work without problems, they'd each have a different port/rpcport assignment.

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).

I don't think that's the case but I will check.

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.

This is happening every day.

Any idea?

No at the moment, there's nothing in the code (that I know of) which could cause that. It'll be worth looking at the hash rate and the tx record for that time of day.

Cheers

Graham