[ANN] Datacoin - Censorship-Free Data Storage

[gjhiggins]

I cannot pick up my  dtc ?
How to transfer coins from one wallet to another?

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

Cheers

Graham

[1714210681]

1714210681

[1714210681]

1714210681

[1714210681]

1714210681

[1714210681]

1714210681

[1714210681]

1714210681

[Chicago]

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.

Hi Graham,

    I've done the protocol upgrade on another network from 0.8 through 0.14.3.
    This should be something we can collaborate on to complete for Datacoin in time to bring 0.16.3 or whatever you like.

    From what I remember, the last Bitcoin protocol upgrade was the August, 2017 upgrade which was brought in by 0.14.2 and then there was the lil fix to make 0.14.3.

    It would make sense the can be no relay of TX between old 0.8 nodes and anything which requires BIP 66.

Best Regards,
-Chicago

[Chicago]

When I did it for the other network, I did it in 3 pieces to go from old protocol to current.

The first network upgrade was just another 0.8 branch release which fixed the difficulty adjustment algorithm.
Afterwards, a 0.13.0 release occurred to usher in BIP66/BIP65 by consensus.
Lastly, a 0.14.3 release was performed to complete the network upgrade.

Along the way, this included the support for BIP 32 as well as a SegWit.

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

Best Regards,
-Chicago

[Chicago]

If y'all know someone who is a merge-mining subject matter expert, I need their assistance with one of the other networks I help to maintain.
It would be cool to have a crew with those skills and then with my background in doing the organic network upgrdes - we could get a lot done rapidly.

[balko14]

What happened to the pool? Why the balance is growing but there are no payments

[minerja]

What happened to the pool? Why the balance is growing but there are no payments

Same here - over 500 coins stuck...

But i have noticed someone is screwing with DTC.

The difficulty was steadily dropping towards 8, and then bam, shot back up to nearly 9 again.
My best guess is that someone is deliberatly letting the diff drop, and then is hitting the pool with massive hash, allowing them to mine many more blocks than normal, then once it slows down, they stop mining, seems to be a pattern to me....totally screwing DTC.

As for me, i was happily mining away with 350 CPD from an underclocked 1030GT wining blocks....then "pow", nothing for last 24 hrs.....

Shame, i think best thing that can happen at the moment is to close the pool, and just make miners use Grahams' wallet with the built-in cpu miner, that way we all might actually get a fair share.....

[gjhiggins]

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

[gjhiggins]

Same here - over 500 coins stuck...

PM me for a refund.

Cheers

Graham

[Chicago]

Same here - over 500 coins stuck...

PM me for a refund.

Cheers

Graham

If it were me, I'd probably also be trying with -zapwallettx and -rescan to abandon the unconfirmed tx.

[Chicago]

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

[soulistyce]

ive put a 50eur  bounty to who ever compiles me a gpu datacoin solo miner here:
https://bitcointalk.org/index.php?topic=5344430.0

[gjhiggins]

If it were me, I'd probably also be trying with -zapwallettx and -rescan to abandon the unconfirmed tx.

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

[balko14]

If it were me, I'd probably also be trying with -zapwallettx and -rescan to abandon the unconfirmed tx.

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

What is no longer sent from the wallet to the exchange? but what to do with the coins on the wallet?

[gjhiggins]

ive put a 50eur  bounty to who ever compiles me a gpu datacoin solo miner here:
https://bitcointalk.org/index.php?topic=5344430.0

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:

Code:

11:11:54

getblocktemplate


11:11:54

{
  "capabilities": [
    "proposal"
  ],
  "version": 536870912,
  "rules": [
  ],
  "vbavailable": {
  },
  "vbrequired": 0,
  "previousblockhash": "50c6dd2f244ab630a2c5934b095b59e11e2c6bac586038fb9ca453dadbc2535a",
  "transactions": [
    {
      "data": "01000000037ba19015a45d2692ecb02efc5cca388fcf1cccd87119c475c30388e912d0aef9000000004847304402200396531a77bd87b3e51211476a7642e9acdafc0b1b056f7247b976f2e303d12e02201d4921e8176f0e220c8620257b301f0cd58ec31d2652e78317e80ed2269ecda501ffffffffb416ddf449daf48110a50c4aa1313625e026fa4a727bd8cc6eefb570d4c06fcd000000006a473044022032ca577e9342049ec6b4e0df858c79da3fd076ed730636148bbc83d5c63611cb02205ea4279e49d4f1e7f100731faab7883033fe2fb74102b98369ef2144fc4848df0121021d325dd3e54ccc5d7c61848ad48124581e12b942739026d48259acfda05f2ccbffffffffc7da48c737cfa4f90f9403e61c03c2114e05eeaf21dff3179f559e0ed7701913000000004847304402206a2a88814063b593f705409771a75dbfedcb814e4dd10907df21ea83a8e8bb22022046019aa1c7d576e9b378041d7e8b675695e3b34ccf5826481309e7050f40021001ffffffff0200a6a63a000000001976a914b94ea4f4d77b11c7cd1d5dc761c6dc748c8f453388ac00e40b54020000001976a9148947c8c9899715177d33a3dff1c9a9744df36f3188acb0f1020000",
      "txid": "2640a60e9f078770384533d3f6c9b212b559dd0ef942763e2d3169e0c69a26b0",
      "hash": "2640a60e9f078770384533d3f6c9b212b559dd0ef942763e2d3169e0c69a26b0",
      "depends": [
      ],
      "fee": 5000000,
      "sigops": 2,
      "weight": 1808
    }
  ],
  "coinbaseaux": {
    "flags": ""
  },
  "coinbasevalue": 3899000000,
  "longpollid": "50c6dd2f244ab630a2c5934b095b59e11e2c6bac586038fb9ca453dadbc2535a366",
  "target": "00000000000000000000000000000000000000000000000000000010a64f0000",
  "mintime": 1624010599,
  "mutable": [
    "time",
    "transactions",
    "prevblock"
  ],
  "noncerange": "00000000ffffffff",
  "sigoplimit": 20000,
  "sizelimit": 1048576,
  "curtime": 1624011114,
  "bits": "0510a64f",
  "height": 192945
}

Cheers

Graham

[gjhiggins]

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:

Code:

...
frontport=6666
serverport=11778
...

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:

Code:

server = "127.0.0.1";
port = "6666";

# Your XPM payout address
address = "DEEboSDviJwFTEWK6VakNuvEz2jGoqc6uR";
...

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

Cheers

Graham

[Chicago]

...I recovered CrossVerse's "madpool" addition, after finally figuring out what it was all about.

Good work! Thanks for focusing on this and telling us about it.

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

Are you at all interested in a IsSuperMajority() network upgrade in a next release using this built-in pool code which could be patched into 0.13.0 (perhaps [or whatever you like]) and then once those are activated, [the IsSuperMajority() forks] continue to lock-in the version bits soft forks?

Since the pool side of the equation and solo mining side of the equation is looking to be more well managed right now, I wouldn't be opposed to doing a white-box generic unpolished but functionally precise wallet to usher in the IsSuperMajority() BIPs.

The hierarchial deterministic wallet comes with 0.13.0 iirc (BIP 32) and activating BIP 66 and BIP 65 with it (but especially BIP 66) will give the Datacoin network a great baseline to then move people out of the 0.8 branch and ensure the problems associated with rejected transactions due to strict DER signatures (to prevent unintentional forks) may be resolved before attempting a SegWit network upgrade.

Also, I will be AFK a ton for the rest of the weekend - but I wanted to just pop in and thank you for the attention you're giving as caretaker for Datacoin and to help with strategy for future protocol upgrades now that more of the mining technology has been wrangled.

Best Regards,
-Chicago

[sampei7777]

Uh-huh, networkhashrate has collapsed.

Is for this reason that the last mined block was #4027220  at  2021-06-21 09:16:58 UTC ?

The problem is in the network, or is me (ByteStamp)?

This morning graymines had 8 workers, now just 1.

It looks like someone is doing this:

-cut-
I could be entirely wrong, but about 3 years ago i had a similar experience, i mined a cpu only coin....its block time was every 2 minutes, but literally no-one was mining it, so the global hash was 1KH/s, i could acheive 65KH/s with just 1 core....so i would solo mine it with 12 threads for approx 3-4 hours, mining a block about every 1-4 seconds, within that 3-4 hours i had mined over 100,000 coins, and then the diff would jump 10 fold, so i would stop, and come back 1-2 weeks later.....when i would find the blocks were coming 1 every 2 mins, and the diff was down at 0.00002414, so i'd repeat.....worked great for about 1 month or 2, then the other miners left, i broke the chain, and couldn't send coins to the 1 and only exchange.
-cut-

More likely, the miner dLeqozLLkdKAQSFJ7evtWCiWNoFcArHngK rightly stopped its activity because he did not receive any DTC due to its segwit address for the payouts.

So, if I understand how PoW works, now we need to wait that someone finds a block at this difficulty. Only then the network will retarget the difficulty at a lower value.

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

I also studied it, because I would like to set up a Datacoin mining pool on ByteStamp servers. But it drove me crazy.

Let me know about it.

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

-cut-

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
-cut-

ByteStamp itself should be a listen node, but obviously ByteStamp does not see itself as a peer.

It should be reachable with

Code:

addnode=dtc.bytestamp.net:4777

Please let me know if it works.

ByteStamp is on your 0.16.3 client since February 2021.


Last but not least, what about to bring Datacoin to a new level?

What I mean is:

smart contracts running on Datacoin blockchain

Sorry for my annoying post , I don't have much time, so I concentrate everything at once.

[soulistyce]

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:

Code:

...
frontport=6666
serverport=11778
...

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:

Code:

server = "127.0.0.1";
port = "6666";

# Your XPM payout address
address = "DEEboSDviJwFTEWK6VakNuvEz2jGoqc6uR";
...

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

Cheers

Graham

im testing in-wallet pool of version 15.99 but its stuck on connecting....network not generating blocks

[gjhiggins]

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:

Code:

addnode=95.217.78.168
addnode=dtc.graymines.net
addnode=113.110.231.187
addnode=51.148.146.204
addnode=dtc.bytestamp.net
addnode=94.63.199.33
addnode=144.76.118.44

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

[gjhiggins]

Datacoin reports #2

Uh-huh, networkhashrate has collapsed.

Is for this reason that the last mined block was #4027220  at  2021-06-21 09:16:58 UTC ?
...
This morning graymines had 8 workers, now just 1.

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