Slightly jumping the gun there, I wasn't ready to announce the release. Users of Windows and OSX 0.8 clients should back up their wallets and save a copy of the datadir directory before attempting an upgrade. The new 0.16.3 client won't load 0.8 wallets, you'll need to import your privkeys by hand. Edit: okay, it does successfully load 0.8 wallets but still do the backup, anyway (always backup the datadir before attempting to upgrade the client). I'm still testing whether the Crossverse 0.15.99 wallets will load. Edit: Meh, had to abandon that, won't compile under 18.04 and just not worth the effort to fix, if the 0.16.3 client can load 0.8 wallets it should also load 0.15.99 wallets okay. (I have to run the 0.8 and the 0.15.99 wallets on an Ubuntu 18.04 VM because neither can be successfully compiled on contemporary Linux distros due to issues with non-backward compatibility of support libraries). Cheers Graham |
|
|
|
My only fault...
Is that you continue to disrupt and dominate this thread with your endless ranting. You've made your statement, now STFU. |
|
|
|
Unlikely. Native English speaker for one and also the depth of experience displayed and sophisticated coding approach taken in the 2014 CRT code (esp. the Evolution code) suggests otherwise. Cheers Graham |
|
|
|
This is my mininginfo. Program changes some parameters after some running times. currentblocksize, currentblocktx, pooledtx.
All quite normal, blocksize will vary (to a maximum) with the number of transactions included in the current block and the poledtx reflects the txs in the mempool waiting to be included. Cheers Graham |
|
|
|
I assert that John Allen Frey was the original developer of Gapcoin
Your assertion may has been proven wrong since j0nn9 (Jonny Frey) has been active on bitcointalk on March 23, 2018! Also he (or his script) has updated http://gapcoin.org/primegaps-length.php on September 10, 2019! I have to agree. BitcoinFX’ assertion falls in the face of considerable evidence to the contrary to what is, after all, a very tenuous string match. In addition to the contradictory evidence already identified by PrimeObsession and previous honest assessment : 1. The soubriquet “j0nn9” was in use in April 2014 by someone calling themselves “Jonny”, working in the crypto arena “Building MaidSafe on ArchLinux”, bylined “Gepostet vor 30th April 2014 von j0nn9” 2. The GAP donation address listed on gapcoin.org has seen activity in 2019. 3. The gapcoin.org website page for “Gapcoin’s highest found merits” carries the headline date “as of 2020 March 31”. 4. The DNS registration for gapcoin.org was renewed on 2020-04-30. The server hosting gapcoin.org is now located in Denmark, according to the DNS resolution, previously the DNS resolved to a German location. 5. The posts, code documentation and comments testify to someone for whom English is a second language. (No implications other than that, j0nn9’s English is a damn sight better than my basically non-existent German.) 6. “Jonny Frey” is not an unknown name in Germany - an examplenovacula OccamiCheers Graham |
|
|
|
Mr. Higgins submit all gaps records !
...
I myself consume a lot of his time ! There is so many questions.
1. Latest commit to the prime gap list - a couple of very solid Gapcoin record merit improvements. (Notification also added to the in-progress community web site.) 2. It's a pleasure 3. Thank you for your support. Cheers Graham |
|
|
|
Have you chosen a NAME for your Hard-Fork?  Not a hard fork, just the Gapcoin reference client with added functionality. Trying to respond to your profound misunderstandings is just a waste of my time, I'll be ignoring your posts here in future. Cheers Graham |
|
|
|
Mod note: consecutive posts merged
Mr. Higgins Coded into Gapcoin-Core a script that regenerates and either destroys coins or shuffles them off to a sock puppet address. I don't have the time or energy to track it down which. Either way avoid using his Software!
You have the wrong end of the wrong stick, as is so often the case. You should have written: avoid using this software but your personal problems are leading you astray. There is - or rather was - an inappropriately-included, development-only piece of code that caused inscriptions to be created when they shouldn't have been, resulting in unspendable txs. Thanks for drawing my attention to the fact that this error was lingering in the gapcoin-project repos, it's just a pity that your personal issues cause you to be quite so abrasively offensive. The description of the gapcoin-project 0.16.3 client repository reads: “Gapcoin Core 0.16.3 Work in progress ” Note the phrase: WORK IN PROGRESS, it's quite clear and moreover, the status description reinforces this: “This branch is 2 commits ahead, 24 commits behind gjhiggins:gapcoin-core.”. I've half a mind to delete the repository entirely in order to protect those who don't know what they're doing from the consequences of their own rash behaviour. Note: All the published pointers to the in-development 0.16.3 client are to my own repository I don't have the time or energy to track it down ...
After 1 Month of the knowledge of it, he has still not changed the Github Source Code.
That's quite hypocritical of you: you can't spare the time but you'll criticise me for not finding the time. What makes you so special? Cheers Graham Note: All the published pointers to the in-development 0.16.3 client are to my own repository Currently, my plan is to make the gapcoin-project 0.16.3 client a minimalist upgrade, preserving only what's absolutely necessary for a Gapcoin port of Bitcoin 0.16.3 (i.e. the obvious cosmetic changes and Gapcoin-specific chain parameter values, some necessary changes to the block structure in order to carry the prime gap data, the replacement of the proof-of-work code, the difficulty modifier code and the reward code). This will make things usefully simpler for anyone else who might want to work on developing the core Gapcoin 0.16.3 client. As for my own enhancements to the 0.16.3 client, I will offer a separate “de luxe” client with source code and binaries available from my own repository. I feel this approach better reflects the decentralised nature of this domain - as I observe elsewhere, there is no “official” this nor any “official” that. Cheers Graham Recently, my time has been taken up with getting the gapcoin-project's “Github Pages” community-led website up, running and populated with content: https://gapcoin-project.github.io/ At the moment, it remains a work-in-progress and not yet finished. Comments welcome. I'll make a later post on how it's “community-led”. Feel free to clone the Gapcoin GH pages repos and contribute. Cheers Graham
|
|
|
|
which colours are diff and hr in wallet ? diff = yellow ?
I don't really know, maybe it's possible to see in the source code? The one that moves around a lot bluey-purple/rgb(145, 137, 255) is hashrate, the one that moves much less orange/rgb(255, 165, 18) is difficulty. Cheers, Graham |
|
|
|
despite being a newbie and maybe that's why I can't report the problems properly
Not newbie: Name: emrgohff Date Registered: 2014-01-21, 10:41:19 And if you can't be bothered to edit your posts properly so that they don't fill up the thread uselessly, I can't be bother to reply in depth. Step one: close client, restart with -rescan=1 option. Wait until complete. Step two: Try sending a small (e.g. 0.25) SLM to an address you control. Stop here. Please report back on whether you can successfully send a tx of 0.25 SLM to yourself. Did you follow these instructions? it is necessary to restart the one in my case it takes about five 30 minutes
That suggests inadequate hardware. This elderly codebase will struggle on old machines. In short, I don't know why the customer closes after making the transaction and still doesn't understand if using "send coins" gives (Error: Transaction creation failed)
Neither do I, no-one else seems to have this problem, looks like it's an issue with your setup. Try exporting your privkeys and importing them into a fresh wallet. If that doesn't fix the problem, nothing will. Cheers Graham |
|
|
|
Shouldn't I have a mempool.dat file in my Slimcoin directory?
No, you'll only find that in clones of Bitcoin 0.15 or later. Cheers Graham |
|
|
|
I understood
Everything ok now
Thanks
Excellent news. Glad you now have full control. Cheers Graham |
|
|
|
The problem is not in the burned coins but in the
Balance = 41.69 SLM (transactions = 75)
Report = 41.69 SLM (transactions = 75)
Coin Control Features = 0 SLM
Coin control was not a feature of the original Slimcoin clone of Peercoin's clone of Bitcoin 0.6, it was backported later. By default, the wallet will choose to collate a set of smaller transactions to make up the intended amount. The original clone is of Bitcoin 0.6 and at this early stage of the development of Bitcoin's codebase, this algorithm is very simple, it starts with the smallest tx values in order. As d5000 has already explained, the "Unable to send transactions" means that in order to make up the total you are trying to send, the wallet has to collate a number of transactions that exceeds the encoded limit. The solution is to gradually reduce the UTXO set by sending very small amounts at first, gradually increasing the amount. Step one: close client, restart with -rescan=1 option. Wait until complete. Step two: Try sending a small (e.g. 0.25) SLM to an address you control. Stop here. Please report back on whether you can successfully send a tx of 0.25 SLM to yourself. If successful, repeat with the amount x 2, continue until "Unable to Send Transaction", go back one step, continue to send that amount repeatedly until all your SLM are collated into a single address. When I did this, I repeated the exercise, working my way down from my total balance until the tx succeeded. And thanks for trying to help, but in my opinion it's from the version code, something is working less well in this version.
You might care to back up your opinion by inspecting the source code: https://github.com/slimcoin-project/Slimcoin and identifying the likely cause of your difficulty. Cheers Graham |
|
|
|
Apertus is no longer under active development, so I suppose it would be fine to interpret .js files, so that they could be run straight off the blockchain.
That might work. What do you have in mind? I thought ownership was a matter of signing a transaction with the Datacoin client, which should be possible in 0.16.
It can be interpreted as such but there's no software support enforcing it (i.e. you can sign any tx but to what effect?) The semantics of the interpretation remains a purely social understanding. Signing a tx doesn't have any inherent meaning as far as the client is concerned. I've had a go at fixing up the 0.16.3 client so that the GUI allows users to create pure OP_RETURN (0-valued) txs. So you can put 0.00 for the value of notarizations (of hashed resources) or TrustyURI inscriptions (“Verifiable, Immutable, and Permanent Digital Artifacts for Linked Data” - I'll write more about them later) - they're not free, they still have a cost - the fee you pay to have the tx included in a mined block and have always been an option - as long as they were specially-crafted and submitted via the creatrawtransaction RPC API call: createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,"data":"hex",...} ( locktime ) ( replaceable )
Create a transaction spending the given inputs and creating new outputs.
Outputs can be addresses or data.
The purpose of the GUI additions that I created is to simplify this process, now you can do the same thing from the GUI without having to craft txs by hand. I'm also looking at the W3's DIDs (Decentralized Identifiers) which can be inscribed via the standard Datacoin txdata mechanism but I suspect users will find some GUI guidance useful. Cheers Graham |
|
|
|
Still down and no response to my post on the above thread. Network hash rate has crashed somewhat which is a shame but ... As sampei7777 observes, the dtc.graymines.net pool is still mining. Go to https://dtc.graymines.net/index.php?id=start for downloadable Windows binaries of the GPU xpmclient poolminer. Miners:
version 10.2 beta, ~260 CPD on GFX 1080.
version 10.1 beta, ~240 CPD on GFX 1080.
version 10.0 beta, ~130 CPD on Radeon 280X, 200 CPD on GFX 1080.
version 9.4.1, version 8.2, ~180 CPD on Radeon 280X.
Sample config.txt server = "dtc.graymines.net";
port = "4444";
# Your DTC payout addressaddress = "DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
# You can give this machine a custom name
# Computer name is used as default
#name = "custom-name";
# GPU crash handling
# Enter OS terminal command here
# for example:
# onCrash = "shutdown -r 1"
onCrash = "0";
# - Valid cpuload range: 0 to 4
# - More than 2 does not make sense
# - You can use 0 for really slow CPUs
cpuload = "1";
# Target Cunningham chain length, default = auto (adjust to difficulty)
target = "auto";
# Sieve size in stripes (1 stripe = 16384 bits)
# Big sieve size gives more candidates with less prime probability
sieveSize = "210";
# Weave depth (primes number count using by sieve)
# Big weave depth increases prime probability, but sieve generate less candidates
weaveDepth = "65536";
# Sieve layers number, optimal value is target*2; default = auto (target*2)
width = "auto";
# Sieve window size
windowSize = "12288";
# Maximal bit size of multipliers using with primorials 13, 14 and 15;
# Default values are 24, 31, 35
# Less values increases prime probability, but sieve generate less candidates
multiplierLimits = ["24", "31", "35"];
# - The following settings have one entry per GPU
# - If you have more than 4 just add more entries or leave it as is to use defaults
# - All entries must be separated by commas and set between double quotes
# 0 = don't use device
# 1 = use device
devices = ["1", "1", "1", "1", "1", "1", "1", "1"];
# sieves per round value, default = 5
sievePerRound = ["5", "5", "5", "5", "5", "5", "5", "5"];
# -1 means don't change; not supported for NVidia
corefreq = ["-1", "-1", "-1", "-1", "-1", "-1", "-1", "-1"];
memfreq = ["-1", "-1", "-1", "-1", "-1", "-1", "-1", "-1"];
powertune = ["-1", "-1", "-1", "-1", "-1", "-1", "-1", "-1"];
fanspeed = ["-1", "-1", "-1", "-1", "-1", "-1", "-1", "-1"];
I have the latest Linux xpmclient-cuda-10.3-linux binary for nVidia GPUs (courtesy of eXtremal's coinsforall.io) which I've got pointed at dtc.graymines.net and is happily running on my old Dell XPS 9560 laptop's built-in GeForce 1050. (I needed to heed its instructions to use xpmclientnv -c to adjust it to handle graymines' use of the older protocol. Cheers Graham |
|
|
|
That said, if you search on bytestamp ( https://www2.bytestamp.net/blocks/qutx) for the transaction id 8b077e4eb862f7ee11ee14f2052430ad1f82b1831ec8b57f652c5cd35932fd88 you can see that there is no such tx in the blockchain. This may suggests that your transaction was never broadcasted to blockchain. You can see this with the command getrawmempool. That is what is implied by the “0/unconfirmed” status. The 0 is "nodes to which this tx has been broadcast". I've had this happen - in the 0.16.3 client there's an option "Abandon Transaction" in the Transactions tab pop-up dialog. I've found that I needed to -rescan -zapwallettxes=2 in order to clear these failed txes from the wallet. In principle, if they're in the mempool, they will likely get sent eventually. Bitcoin 0.16.3 has a fee-replacement scheme that you can use to bump up the fee to that it is more attractive to miners - but that's a feature of the Bitcoin network and unlikely to be of much use in a Datacoin context. But... if you go to https://dtc.graymines.net/index.php?id=blocksyou can see that block # 3873054 was found by the address: dc1q94pvtll03nsfrgn9felgtnzv98836huzk2nddp That is not a legacy address but a segwit one. So? Have we switched to Segwit? Grahams? No, it's possible that someone who isn't familiar with the new extended keys doesn't know to use addresstype=legacy in the config file. dig dtc.graymines.net resolves to 89.73.143.76 - which is reported by getpeerinfo to be “/Satoshi:0.8.5/”. I have just checked an 0.8.6 client (after some struggles to get it to compile under Ubuntu 0.18, see below) and it reports that address as invalid, so I doubt that graymines was able to send that reward. Not sure what's happening with the network, my remote server reports the following clients seen atm: 123.125.148.46:4777 - /Satoshi:0.8.3/
102.165.224.64:61137 - /Satoshi:0.8.3/
89.73.143.76:4777 - /Satoshi:0.8.5/
95.217.78.168:35254 - /Satoshi:0.8.5/
[2a01:4f9:4a:1e17::2]:46230 - /Satoshi:0.8.5/
85.19.25.38:6390 - /Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/
150.143.207.111:53560 - /Satoshi:0.8.6/Datacoin:0.1.2(v0.1.2.0dtc-hp14-gunk-beta)/
140.186.218.230:50890 - /DatacoinCore.Veter:0.15.99.8/
40.87.106.229:62839 - /DatacoinCore.Veter:0.15.99.8/
31.131.65.221:60853 - /DatacoinCore.Veter:0.15.99.8/
150.143.207.111:61269 - /DatacoinCore.Veter:0.15.99.8/
45.33.238.99:33943 - /Datoshi:0.16.3/
108.160.136.247:51398 - /Datoshi:0.16.3/
79.114.44.38:49627 - /Datoshi:0.16.3/
51.148.146.204:56982 - /Datoshi:0.16.3/
51.148.146.204:59944 - /Datoshi:0.16.3/
51.148.146.204:34232 - /Datoshi:0.16.3/
51.148.146.204:34234 - /Datoshi:0.16.3/
45.63.115.238 - ""
As regards switching to segwit ... Given that the 0.16.3 client retains the versionbits code required to effect the transition via soft-fork, one possible roadmap to segwit is: 1. After a majority of users have upgraded to the 0.16.3 client ... 2. At some widely-advertised point, the versionbits code is enabled to create a specific window of time 3. Users then download and use the new versionbits-enabled client, signalling their willingness to accept the change to segwit 4. When the window of time expires, assuming the majority of users are using the versionbits-enabled client, the change becomes permanent. 5. At some widely-advertised point, the block and transaction versions are bumped, excluding the old clients from the network 6. A majority of users update to this new client. As far as I can tell, atm there are three Datoshi 0.16.3 client operating (other than the ones I’m running on 51.148.146.204), one somewhere on rdsnet.ro, one on digisoftsrl.it and one on vultr.com and as I haven't actually released the 0.16.3 client (I'm still trying to ensure it is working as expected), any progress towards a network upgrade is likely to be leisurely at best. Although the existing compiled binaries of the 0.8 clients remain functional, the 0.8 sources are increasingly falling out of scope. They no longer compile successfully with the systems packages of contemporary OS distros, requiring some configuration acrobatics to compile with self-built legacy libraries for openssl and boost. Cheers Graham |
|
|
|
in the last couple of weeks i have lots about 30,000 DTC in various transfers...
Status: 0/unconfirmed
You may well not have lost the coins if the transactions haven't been broadcast and confirmed. Backup your wallet, then close the client and restart it with the options -rescan -zapwallettxes=2i like the chainz.cryptoid.info one where i can check block height, and check peers....
No-one renewed the subscription, so they removed the service. Cheers Graham |
|
|
|
In fact this is working a little bit like Apertus, but in the client itself.
It's limited to rendering HTML pages. Didn't want to tread on toes. With the Datastore function are we effectively creating Non-fungible tokens?
Depends on what you inscribe and there's no direct means of asserting ownership nor is there any kind of ownership transfer mechanism. So yes but only notionally. Cheers Graham |
|
|
|
coinsforall.io was in destroyed SBG2 (with backups), now reopened.
Bummer. Good that you could re-open so soon. Looks like you took the opportunity to close the Datacoin pool? Cheers Graham |
|
|
|
|
Show Posts
