Topic: [ANN] Datacoin - Censorship-Free Data Storage - page 3. (Read 66642 times)

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

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:


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.


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.


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

It should be reachable with



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.

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


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

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:

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:

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

Cheers

Graham

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:


Cheers

Graham

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

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

ive put a 50eur  bounty to who ever compiles me a gpu datacoin solo miner here:
https://bitcointalksearch.org/topic/bounty-50eur-to-compile-miner-5344430

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


Best Regards,
-Chicago

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

PM me for a refund.

Cheers

Graham

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

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

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

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.

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

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

Cheers

Graham

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

thanks for the support