Got another question for you j0nn9 - I'm using windows 7 for my wallet. I have another win7 machine running the rpc miner with no problems. When I try to introduce the rpc miner to a 3rd windows machine, it seems that it cannot connect to the wallet. I get the same message printed over and over again - curl_easy_perfomr() failed: Timeout was reached
waiting for gapcoind ... Any idea why? It seems that it connects, but Gapcoin is not responding in time. Is it a very slow pc? Currently you cannot change the timeout. This will be changed in the next release. But you can also mine with the wallet, it should be equal. |
|
|
|
Yes, it should be accurate, did you mined some orphans? You could try adding these nodes to your config: addnode=212.227.143.155
addnode=104.131.69.82
addnode=95.215.44.9
addnode=155.254.36.179
addnode=199.127.226.192
|
|
|
|
just wondering if someone could tell me what a few of those lines mean like "seivesize" "seiveprimes" and "pooledtx"
"blocks" : 3778,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 20.82454605,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"sievesize" : 1048576,
"sieveprimes" : 500000,
"shift" : 20,
"primespersec" : 15617,
"10gapsperhour" : 0.00000000,
"15gapsperhour" : 0.00000000,
"gapsperday" : 1.21937143,
"networkprimesps" : 7571792,
"pooledtx" : 0,
"testnet" : false
}
sievesize = the size of the sieve used for prime search, this should be not greater than 2^shift 256 + shift = the bit size of the prime you are searching for. shift have to be greater than 13. sieveprimes = the number of primes you sieve. The more primes you sieve, the less prime tests you have to calculate. But to much sieve primes will also slow down mining. pooledtx = number of transactions in the memory pool |
|
|
|
Thanks for your efforts! If you set up a faucet, i will donate some GAP.
The faucet is ready: https://bchain.info/GAP/faucetI've set it to 0.05 gap per request. Thanks! 20 GAP were sent. |
|
|
|
Thanks for your efforts! If you set up a faucet, i will donate some GAP. |
|
|
|
Hey guys I'm having an issue with the gapcoin daemon. I'm running into the following error.
listreceivedbyaddress GMQTf3GUtB1kFSv1tmDYhvdDzdnPBiyu3X
error: Error parsing JSON:GMQTf3GUtB1kFSv1tmDYhvdDzdnPBiyu3X
I deal with 50+ daemons and this is the first time i've come across this error.
Can anybody share some insight.
Seems like you discovered a bug. But the proper way to use this rpc call is: listreceivedbyaddress ( minconf includeempty )
List balances by receiving address.
Arguments:
1. minconf (numeric, optional, default=1) The minimum number of confirmations before payments are included.
2. includeempty (numeric, optional, dafault=false) Whether to include addresses that haven't received any payments.
Result:
[
{
"address" : "receivingaddress", (string) The receiving address
"account" : "accountname", (string) The account of the receiving address. The default account is "".
"amount" : x.xxx, (numeric) The total amount in btc received by the address
"confirmations" : n (numeric) The number of confirmations of the most recent transaction included
}
,...
]
Examples:
> gapcoin-cli listreceivedbyaddress
> gapcoin-cli listreceivedbyaddress 6 true
With the right arguments, it doesn't shows an error. |
|
|
|
j0nn9 i would propose that you write on the title of the OP something like that 'New Math Algo - CPU only'
also 'decentralized' is pretty much obvious since it is a bitcoin based cryptocoin...
My title would probably be: [ANN][GAP] Gapcoin-Searching for Prime Gaps-New Math Algo-CPU only-Zero Premine
Many people are searching for CPU coins and are interested in new algos but the title wont probably attract them.
Thanks for your suggestion, i've edited the title. Also is there thinking about decreasing time required for block reward halving? Since rewards are actually getting raised a bit with diff and since today is not 2009 anymore i would argue that 2 years for halving is rather much. I would propose a quite fast halving time of 6 months or even more aggressive like 3 months. My thinking is that this way it would trigger more speculating and faster. And even if it is too steep and probably create bubble situations it would also probably generate enough pressure so that we can have nice hashrate peaks rather early and try to break some records. 2 years halving time seems a bit rather stagnating especially in a crypto world that everythig changes every half a year.
I would like to see some chat on that matter. Especially now that the coin is 5 days old and noone is going to have the upper hand.
This would imply a hard fork. So, i would only consider it, if there is a wide approval for it. |
|
|
|
The miner simply finishes without errors/messages.
Could you make a valgrind memcheck dump or something similar, to trace back the problem. |
|
|
|
where do I add setgenerate exactly ?
help > debug window > console setgenerate true |
|
|
|
Not finding any blocks for quite a while....anyone else?
I am mining on 6 different comps ranging from 10-30k pps.
I am using setgenerate true from wallet, should I be using something else?
I had something similar, and found that my comps were kinda finding blocks, but most were orphans due to not keeping up with the network (comparing my top block to the block explorer top block). I've been watching my network connections, thinking it might have something to do with losing connectivity to nodes so it just stays on some blocks for longer than it's supposed to. I added all the nodes in the OP too, but I haven't found any blocks that I know of since I started watching it. I've got 43k pps, so they're usually quite a few hours inbetween. I did find two legit blocks today though, so big win from the last few days when I ended up with 1 block on the 23rd, 1 block on the 22nd, and 3 on the 21st. OK thanks thats is similar to my block finds between comps, thanks. Hopefully others can weigh in their results as well, or the dev can tell us if this is correct. Gapcoin has the listed nodes hard coded, but if you did not add them to your config, it uses them only for the initial connection and then connects to random nodes. So yes, it could be that you got some weak one. Adding the listed nodes could help, but if everyone connects to them, then they will become the "weak nodes" because of the heavy network load. |
|
|
|
I've been working to implement the algo in stratum for the last few days so I can get a pool up but it's not easy, and will take at least a few more days. It's been one hell of a C++ / C learning experience however!
Is anyone working on a non rpc miner?
Hey, that are great news! pm me if you have any questions about the algo. |
|
|
|
Are there any more addnodes?
The current nodes, should be enough. They also are hard coded into Gapcoin. So it should automatically connect to the network even without the nodes in your config. Once it connects, it loads more nodes and connects to them. This means that except for the initial connection, you end up connecting to random nodes on the network. |
|
|
|
[2014-10-24 23:40:26] pps: 34837 / 34249 10g/h / 15g/h / [2014-10-24 23:40:36] pps: 35186 / 34256 10g/h / 15g/h / [2014-10-24 23:40:46] pps: 35285 / 34264 10g/h / 15g/h / [2014-10-24 23:41:05] pps: 35083 / 34280 10g/h / 15g/h / Got new target: 20.2047 how do you know what speed I  pps are your primes per second. 34280 is actually pretty good, what cpu are you mining on? Maybe we can create a hardware comparison page on the website. |
|
|
|
Published Windows binaries for gapminer. Usage: You have to edit the start-gapminer.bat and fill in your rpcuser and rpcpassword from your gapcoin.config. Also add "server=1" to your config. |
|
|
|
One question about the algo and the records. So we have to reach 35.4245 difficulty.
Does that means that if hashrate never gets bigger we wont find record prime gaps?Even if we mine for much more time?
What hashrate should the network have so that we can reach that difficulty? I want to realize how fast we can actually reach that. Will it take some months or a year or 10 years?
Of course i understand that better miners will come out and pools will help but i want to have a comparison.
It's not neccesary that the difficulty reaches 35.4245, we already have two ~28 merit gaps: [
{
"time" : "2014-10-21 19:41:01 UTC",
"epoch" : 1413920461,
"height" : 240,
"ismine" : false,
"mineraddress" : "GXk8PfPwuDXQN5iQAypQFmS1LxArXtfY2L",
"gapstart" : "67692237123843296659418251254586218470394655850041287301830823121119920971930198957",
"gapend" : "67692237123843296659418251254586218470394655850041287301830823121119920971930204303",
"gaplen" : 5346,
"merit" : 28.02997943
},
{
"time" : "2014-10-22 06:07:49 UTC",
"epoch" : 1413958069,
"height" : 737,
"ismine" : false,
"mineraddress" : "Gcagtj5wCDHai4tJqJqTLTFwLBDaJnAA5u",
"gapstart" : "94715185144650972004538857957041135176651988819124169310707053830636479917687941569",
"gapend" : "94715185144650972004538857957041135176651988819124169310707053830636479917687947043",
"gaplen" : 5474,
"merit" : 28.65064563
}
]
You can use the "listbestprimes" rpc-call to list the gaps with the currently greatest merit. Within the test networks the greatest merits were mostly about 9 times greater than the difficulty, so we hopefully only need to reach a difficulty of 27. |
|
|
|
Released gapminer linux binaries, windows will follow. Miner compiled by me on Intel for Linux, did not work for AMD. When I compiled on AMD all was adjusted. When you compile the miner on your own it uses spectial compile flags for tuning, like: "Native" means that the code produced will run only on the CPU which compiled it. The published binaries were not built with that type of optimation, meaning they will run on both amd and intel. |
|
|
|
Released gapminer linux binaries, windows will follow. |
|
|
|
|
Show Posts
