I maintain the icoin-project repository at GitHub where the v1.4.0.0 release has been tagged. This coin's code is basically stalled right now and I haven't worked on it for a long time. The roadmap for iCoin is as follows: perform a network protocol upgrade form the old v0.6 Bitcoin code to modern Bitcoin sources. I can go into depth about it here if anyone else has developmental interests. It's basically a doable task, but doesn't happen without me or somebody doing it. I still like iCoin and want to help though I have been detached from working on crypto stuff for the past two years w/ the pandemic crap and the world going crazy. Best Regards, -Chicago |
|
|
|
Hi Graham, 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.
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. Apologies for the delay in my responding to your kind words and positive suggestions. Do you feel that it's worth the effort? I feel like once bitcoins are a ubiqutous currency globally and the hurdles El Salvador is facing with the IMF and World Bank have been overcome, it will be a short time thereafter where new faces will surge into many of the original communities which still have the will to live. I don't think we need to go the scenic route here but its certainly a possibility we can entertain as well.
I have spent some time thinking about this in depth but I just can't convince myself that there is sufficient residual interest in the Datacoin chain to justify the amount of effort required for a migration. I like to think of network maintenance and protocol upgrades for the Satoshian derivatives which are closely linked to original Bitcoin sourcecode as heavily modular. In the case of Datacoin we really have just two differences making us more unique than the myriad Scrypt altcoins. We use the Sunny King pieces for proof-of-work and retargeting and we have added an additional field into the transaction. So when I imagine what it would look like for me to start building a new client to usher in the next protocol level - I see myself making commits which nearly mirror my prior work and then only have to "think" when it comes to the part which makes us distinct (the proof-of-work, retargeting and patching in the additional transaction field). That is to say, most of the effort would be textbook processes and procedures where the work product is much more refined and elegant, yielding a more controlled network upgrade. Is it worth the effort? I don't know, but I tend to like the older less perfect networks more than the newer more experimental projects which are not based on tried and true upstream Bitcoin code. There isn't even enough interest to protect the chain against the current exploitation by just one individual of the emissions rate/difficulty modifier relationship.
This is a real problem. The other issues are less important than the actual network security which is quantified by the proof-of-work mining the emissions. We could potentially pivot to auxiliary proof-of-work and seek out the goodwill of some merge-mining pool operators. This would at least keep some of the smallest fish from abusing the chain continually and trade it for potential abuse from a bigger fish taking in nearly all of the rewards (but almost always certainly putting them up for sale) [which makes their share of the pie more manageable]. I'm certainly interested in your philosophy about long-term maintenance for mostly dormant network communities. Although I see myself as merely an occasional technical contributor, I can see why public perception may prefer a caretaker interpretation.
My mistake, you used the word curator years ago in reference to leadership here and I couldn't remember 100% and wrote caretaker when I meant to use the word you gave in your self-defined role. The community seems to have evaporated leaving a few isolated individuals remaining. Communication ranges from terse to non-existent.
Even though y'all in this thread aren't a daily part of my life -- I still like you more than the prospect of getting involved with any other flavor-of-the-day project which has less favorable politics. I like Datacoin because it provides a medium to preserve free speech. What's the point of continuing to support the remnants of a community that don't appear to want support?
Once network security is solved we will be able to transform from preserving free speech to protecting free speech - and in my mind this justifies continuing support. Best Regards, -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 |
|
|
|
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 |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
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 |
|
|
|
what I posted is the statistics of the arrival of coins on the exchange from one pool and from another with the same SPD
Okay, that makes a bit more sense then. So, what is the actual problem you want to solve? Are you just trying to figure out if the pool payouts are honest? |
|
|
|
compare the payout of the pool coinsforall where 1000 DTC and the payout of the pool dtc.graymines where 50 DTC speeds are the same and income per hour
1101357
8ff97abb33... +1002.39424591 0.00000000 OK 15:30:06 08/03/2021
Hi Balko, Let's look at the data you pasted here. First, I see what looks like a height. 1101357 Next, I see what looks like the beginning of a block hash. 8ff97abb33... The next two fields look like a representation the subsidy and something else (maybe difficulty or maybe fees). +1002.39424591 0.00000000 The last two appear to be a verification result and a timestamp. OK 15:30:06 08/03/2021 My point is those are nonsense results for the main Datacoin network. The heights in your paste happened 6 years ago (Sun Nov 22 2015 00:17:56 GMT+0000). {
"hash": "7a34762ae2e5a57fd6822bd5e323668bd1830f8dcaf4e559e589f8578c54534a",
"confirmations": 2881889,
"strippedsize": 201,
"size": 201,
"weight": 804,
"height": 1101357,
"version": 2,
"headerhash": "ff2ee2e8ef475b9cdfa41ea8443c931234caebd04771b6659c7c47e9b3697816",
"versionHex": "00000002",
"merkleroot": "57469605f03c4173a552f9898b0a08da425bcdcbc0f122e691e1acefc51cb2e4",
"tx": [
"57469605f03c4173a552f9898b0a08da425bcdcbc0f122e691e1acefc51cb2e4"
],
"time": 1448151476,
"mediantime": 1448146176,
"nonce": 1383779704,
"primechainmultiplier": "194141584236906711040",
"bits": "08fb3093",
"difficulty": 8.981209933757782,
"chainwork": "00000000000000000000000000000000000000000000000000001018ffee9c5d",
"nTx": 1,
"transition": 9,
"primechain": "TWN00.000000",
"primeorigin": "22408329804299343599408431215969857786164394850963318879641955955131239393639425443486854099742720",
"previousblockhash": "186fbb67b9f2c05281bebc48ffd78a225d09ca11bdbe9804233d1f8b4ab1a6ff",
"nextblockhash": "dd589776d292bcb73c5a07a6a4ab8cbebfc8dbf222291658e0cb959fa441c760"
}
Since I don't operate coinsforall, its not for me to say what was happening there. Nonetheless, with the data you presented which speaks for itself - there was something else being mined. Best Regards, -Chicago |
|
|
|
1101067
3905d67ad3... +1003.66754629 0.00000000 OK 09:36:07 08/03/2021
1101033
9a275ffdd5... +1007.41278555 0.00000000 OK 08:57:06 08/03/2021
1100992
364e7f0457... +1000.06218336 0.00000000 OK 08:06:07 08/03/2021
1100958
b468a22307... +1006.27759303 0.00000000 OK 07:27:06 08/03/2021
1100921
fbaf38a498... +1000.77707421 0.00000000 OK 06:36:07 08/03/2021
1100897
822805ac01... +1000.22591080 0.00000000 OK 05:57:06 08/03/2021
1100857
18427de1c4... +1000.15272519 0.00000000 OK 05:06:06 08/03/2021
1100823
4aef82c2fb... +1001.32324665 0.00000000 OK 04:15:07 08/03/2021
1100788
65f4057845... +1007.08727809 0.00000000 OK 03:36:06 08/03/2021
1100758
088d877e6a... +1008.32886653 0.00000000 OK 02:45:05 08/03/2021
1100731
0b1c548469... +1007.45672812 0.00000000 OK 01:54:06 08/03/2021
1100717
cdf92e7d08... +1003.12011732 0.00000000 OK 01:15:07 08/03/2021
1100685
5788d9c741... +1007.12455927 0.00000000 OK 00:33:07 08/03/2021
1100665
d426ebd0a8... +1008.10140777 0.00000000 OK 23:54:06 07/03/2021
1100630
a477f5c424... +1006.05571180 0.00000000 OK 23:12:08 07/03/2021
1100584
7769ddfa70... +1002.09770111 0.00000000 OK 22:33:06 07/03/2021
1100548
6051523ef9... +1003.42751877 0.00000000 OK 21:42:07 07/03/2021
1100527
3977551c13... +1002.41646186 0.00000000 OK 21:12:06 07/03/2021
1100500
fcf5a90d0d... +1003.23516997 0.00000000 OK 20:33:06 07/03/2021
1100466
5093f5c68f... +1002.76044727 0.00000000 OK 19:51:06 07/03/2021
1100436
fb551cd52b... +1006.30450988 0.00000000 OK 19:12:06 07/03/2021
1100422
2f68613840... +1005.27385475 0.00000000 OK 18:42:06 07/03/2021
1100393
eca969eb27... +1007.24999394 0.00000000 OK 18:00:06 07/03/2021
1100353
04a1588b2b... +1001.55566346 0.00000000 OK 17:12:07 07/03/2021
1100327
7f35146b20... +1000.27305002 0.00000000 OK 16:42:06 07/03/2021
1100284
af98a92204... +1008.21185792 0.00000000 OK 16:00:06 07/03/2021
1100205
cc03623e4b... +1004.19525209 0.00000000 OK 15:30:06 07/03/2021
1100179
41e7a22297... +1008.71403214 0.00000000 OK 14:51:06 07/03/2021
1100154
312d7992fa... +1000.02834920 0.00000000 OK 14:21:06 07/03/2021
1100119
bdf65e4cb6... +1001.72623867 0.00000000 OK 13:39:06 07/03/2021
1100101
2e2bf23434... +1005.49985118 0.00000000 OK 13:09:06 07/03/2021
1100059
b2e11c5148... +1007.36684982 0.00000000 OK 12:30:06 07/03/2021
1100037
91e0a1985f... +1002.83335557 0.00000000 OK 11:57:07 07/03/2021
1099992
1ed43cb3a0... +1005.28958256 0.00000000 OK 11:06:06 07/03/2021
1099968
8d249b3234... +1007.97271861 0.00000000 OK 10:36:06 07/03/2021
1098291
779b984cc7... +1000.36496782 0.00000000 OK 09:48:07 07/03/2021
1098260
4e3c67def9... +1005.57859101 0.00000000 OK 09:15:06 07/03/2021
1089303
973d5fccbc... +1005.76925362 0.00000000 OK 19:27:07 26/02/2021
1089271
65e4a1e942... +1001.66197101 0.00000000 OK 18:18:07 26/02/2021
Those block numbers 1089271..1101067 don't look right to me. The first height, 1089271 is actually from Tue Nov 10 2015 04:48:52 GMT+0000. {
"hash": "1b92606f98a2e58f8bd4f9fd2761a3cbe80ffa3ea8d9fd49867d50aa2d1a6e07",
"confirmations": 2415892,
"strippedsize": 201,
"size": 201,
"weight": 804,
"height": 1089271,
"version": 2,
"headerhash": "e4b38106a5ab28d0c309452d030b687e237cd7c5a4f202a966290a95c210bac0",
"versionHex": "00000002",
"merkleroot": "72b9ec6872f50edb73102c9c7e4a131974a152a303916b90ec4f0a4e8d291623",
"tx": [
"72b9ec6872f50edb73102c9c7e4a131974a152a303916b90ec4f0a4e8d291623"
],
"time": 1447130932,
"mediantime": 1447126638,
"nonce": 366105561,
"primechainmultiplier": "23377665770782809200",
"bits": "08fe1ff6",
"difficulty": 8.992675185203552,
"chainwork": "000000000000000000000000000000000000000000000000000010078f0f410b",
"nTx": 1,
"transition": 9,
"primechain": "TWN00.000000",
"primeorigin": "2418290610329150623773687133567610215196245824803210430165269096060232090523863171712843164595200",
"previousblockhash": "f2317ed27e3ad42a00cb8b02189b7875da17d90424e38c6a3419eb84c30cbb22",
"nextblockhash": "829f56f552d9eeadae62025aebcb04bd6ac373afe5cd0612c9157261d6210d23"
}
The last height, 1101067 is actually from Sat Nov 21 2015 16:05:23 GMT+0000. {
"hash": "696855c709c97635132433c730ac45905cfc44f787ff3cdb2a37898a580a380c",
"confirmations": 2474703,
"strippedsize": 201,
"size": 201,
"weight": 804,
"height": 1101067,
"version": 2,
"headerhash": "eec41749b39864f5cb7818aa2bbc2553d7c9f8fcedbff496c26d11bb7d959a84",
"versionHex": "00000002",
"merkleroot": "598667627def23eb92b46f853aab1c69c49b7efebd97f97dc73b9c349869187f",
"tx": [
"598667627def23eb92b46f853aab1c69c49b7efebd97f97dc73b9c349869187f"
],
"time": 1448121923,
"mediantime": 1448115238,
"nonce": 1718020612,
"primechainmultiplier": "12153070004435888640",
"bits": "08fb6028",
"difficulty": 8.981935977935791,
"chainwork": "00000000000000000000000000000000000000000000000000001018a3938025",
"nTx": 1,
"transition": 9,
"primechain": "TWN00.000000",
"primeorigin": "1312494137708892454461758721723977354712236141821654798902430944422957895343783884342144922920960",
"previousblockhash": "1c521a740e2a5533f7d1f76e7a8f409e4bdae4e00a02c7b187b268d4daf605e9",
"nextblockhash": "3f937e2307f53d9ec509eab6e9f0d2a6c4441a45c8603f48a517598833e76664"
}
Therefore, it doesn't appear you are mining datacoins on the Datacoin block chain. Best Regards, -Chicago |
|
|
|
|
Now I know why they don't have the Engineering guys running the Sales department.
|
|
|
|
Not sure to understand you, did you mean faster blockchain at 128kb
What I mean is -- when you broadcast a transaction with 128KiB of data within it you will want the TX distributed through the network so it can easily be included by miners in the next block. A limit of 128KiB makes it possible for even the most limited peers to be able to verify and relay the transaction in a relatively short period of time. big file are writen on multi TX ?
The "how to" is up to you. Think of it like splitting a file into multiple chunks where part 1of8 is in one transaction and part 2of8 is in another transaction. In this way you are able to spread a large upload across multiple transactions. If you're familiar with Usenet and the alt.binaries newsgroups, it would be similar to seeing a nice large upload split across dozens of posts. Best Regards, -Chicago |
|
|
|
I try to see what purpose this coin can fill. Seem very limited at 128kb
The data transport mechanics are up to you. If you want to send a megabyte in 8 parts, then you segment the payload into 128KiB sized pieces and write it to the chain. After it has been enscribed, then the chunks may be re-assembled into their more useful format. Small TX limits are helpful to promote swift propagation throughout the network. Best Regards, -Chicago |
|
|
|
Pool dtc.graymines.net SCAM
I've been on a break from financial hobbies since the pandemic started and I came here today just to tell you I think you're wrong. Also, scam accusations need to have some substance and details which are of empirical value. How long did you mine? How long did you wait for the reward to mature? How do you know you were scammed? |
|
|
|
Alternatively, if you would be willing to transfer over to me all luckycoin access (github, any material) I am willing to pay you for the privilege.
The plan is to 'upgrade' lucky coin but maintain the core principles of the coin (dynamic block rewards).
If you are open to the idea, or even if you are not, if you could respond I would greatly appreciate it.
This isn't a bad idea. There are also probably some other threads from almost a decade ago which also are linked to older GitHub repositories. |
|
|
|
If no one wants to close the pools and help lower the diff, perhaps the only other option is to hardfork....have to say that most coins i see hardfork, usually die quite soon afterwards thou, so thats not an option i would vote for....
The development agenda does include activating protocol which was never enabled for us during the upgrade from 0.8 to 0.16. I've spoken briefly about it in the past. We can simply build clients with updated chain parameters (in source) and require miners to eventually create blocks in the new format (the regular upgrade process we skipped which uses IsSuperMajority and BIP 9 deployment). This is at a standstill right now and has been for me ever since the 0.16 code failed to run and mine for the testnet. |
|
|
|
i'm currently using wallet "datacoin-0.8.6.0-linux" and it appears fine, bit slow to open, and very slow to sync compared to say Primecoin wallet. So i think the wallet needs some more optimising.
(I opened DTC and XPM wallets together, DTC was 39 hours behind, and XPM 6 weeks,,,,,DTC is still 11 hours behind, and XPM has synced)
This is not really a Datacoin problem. The derivatives of the upstream Satoshi reference client in the 0.8 branch run dogshit slow. We have over 3.4+ million blocks. Faster synchronization happens with the newest code. |
|
|
|
configure: error: libdb_cxx headers missing, Datacoin Core requires this library for wallet functionality (--disable-wallet to disable wallet functionality)
You're missing the Berkeley DB packages. Unix Build Notes |
|
|
|
not mine, perhaps Chicago's? he was active back then.
Not mine either - I haven't moved anything in years. |
|
|
|
|
Show Posts
