[GRP] GRouPcoin

[RoadTrain]

Actually, KrLos, if you read THIS VERY PAGE, you'll see that there is now an updated version (though experimental) with a more recent bitcoind/bitcoin-qt base.

And it seems to work well, though I'd appreciate some feedback  
After all I could move on to other merge mined coins to update their clients.

Had floating point exceptions when downloading full blockchain.  Can't be bothered forking in github but here's a patch:

Code:

--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1115,8 +1115,8 @@ unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBl
     if (pindexLast == NULL)
         return nProofOfWorkLimit;

-    if (pindexLast->nHeight < 9500)
-        nTargetTimespan *= 14; // two weeks
+    // prior to block 9500 2 weeks.. daily after
+    nTargetTimespan = (pindexLast->nHeight < 9500) ? 1209600 : 86400;
     int64 nInterval = nTargetTimespan / nTargetSpacing;

Only quickly tested daemon on ubuntu 12.04 x64 but seems to work.

Well it should be equal, there's no floating point math used.
Do you have any logs?

Original version increases nTargetTimespan for every GetNextWorkRequired with block < 9500.  
This is used in some modulo operations later which I'm guessing eventually result in a div 0 after it overflows.
Also, couldn't see where it would be set back to 1 day on block 9500, without restart?

For any block earlier than 9500 nTargetTimespan is 14 days, 1 day thereafter.
It's exactly what my code does, the same code is used in old client.

Code:

unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast)
{
    const int nSmoothBlock = 9500;
    const int64 nTargetSpacing = 10 * 60;
    int64 nTargetTimespan = 24 * 60 * 60; // one day

    if (pindexLast->nHeight < nSmoothBlock)
        nTargetTimespan *= 14; // two weeks
    int64 nInterval = nTargetTimespan / nTargetSpacing;

[1713239406]

1713239406

[1713239406]

1713239406

[1713239406]

1713239406

[hendo]

Actually, KrLos, if you read THIS VERY PAGE, you'll see that there is now an updated version (though experimental) with a more recent bitcoind/bitcoin-qt base.

And it seems to work well, though I'd appreciate some feedback  
After all I could move on to other merge mined coins to update their clients.

Had floating point exceptions when downloading full blockchain.  Can't be bothered forking in github but here's a patch:

Code:

--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1115,8 +1115,8 @@ unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBl
     if (pindexLast == NULL)
         return nProofOfWorkLimit;

-    if (pindexLast->nHeight < 9500)
-        nTargetTimespan *= 14; // two weeks
+    // prior to block 9500 2 weeks.. daily after
+    nTargetTimespan = (pindexLast->nHeight < 9500) ? 1209600 : 86400;
     int64 nInterval = nTargetTimespan / nTargetSpacing;

Only quickly tested daemon on ubuntu 12.04 x64 but seems to work.

Well it should be equal, there's no floating point math used.
Do you have any logs?

Original version increases nTargetTimespan for every GetNextWorkRequired with block < 9500.  
This is used in some modulo operations later which I'm guessing eventually result in a div 0 after it overflows.
Also, couldn't see where it would be set back to 1 day on block 9500, without restart?

For any block earlier than 9500 nTargetTimespan is 14 days, 1 day thereafter.
It's exactly what my code does, the same code is used in old client.

Code:

unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast)
{
    const int nSmoothBlock = 9500;
    const int64 nTargetSpacing = 10 * 60;
    int64 nTargetTimespan = 24 * 60 * 60; // one day

    if (pindexLast->nHeight < nSmoothBlock)
        nTargetTimespan *= 14; // two weeks
    int64 nInterval = nTargetTimespan / nTargetSpacing;

Sorry for flogging a dead horse but not quite...   

In the new fork, nTargetTimespan is global (i.e. will be multiplied by 14 every call, and eventually overflow).  If the above snippet is original client, it is local and so will behave as expected.
Am guessing it is global now as was referenced in some other function/s, otherwise making it local would have been the better fix. 
You might want to check if mutating the value on the fly will affect any other usages of it too.

I'm assuming we are both looking at the same code, branch i0coin-0.8.x was default in git?  If not my humble apologies.

[RoadTrain]

Sorry for flogging a dead horse but not quite...   

In the new fork, nTargetTimespan is global (i.e. will be multiplied by 14 every call, and eventually overflow).  If the above snippet is original client, it is local and so will behave as expected.
Am guessing it is global now as was referenced in some other function/s, otherwise making it local would have been the better fix. 
You might want to check if mutating the value on the fly will affect any other usages of it too.

I'm assuming we are both looking at the same code, branch i0coin-0.8.x was default in git?  If not my humble apologies.

Well I think I'm starting to understand Forgot about it being global. I'll try to resync from scratch to check and update code if needed. Thanks.

[bitpop]

What's going on here

[RoadTrain]

Fixed retarget issue, added a checkpoint and a couple of nodes.
https://github.com/RoadTrain/groupcoin

[markm]

I grabbed RoadTrain's version from github, it seems to be working fine for me so far...

-MarkM-

[RoadTrain]

I grabbed RoadTrain's version from github, it seems to be working fine for me so far...

-MarkM-

Just in case you have GRP logo or icon, I'd be glad to update the repo.
Cause GRP with I0C logo looks a bit...

[K1773R]

I grabbed RoadTrain's version from github, it seems to be working fine for me so far...

-MarkM-

Just in case you have GRP logo or icon, I'd be glad to update the repo.
Cause GRP with I0C logo looks a bit...

most ppl dont use qt anyway

[IYFTech]

A logo would be nice though.......

[Asphyxiated]

I just recently started merged mining on bitparking so I had to get a groupcoin wallet, I did get the GUI version to compile. Although it seems that it was been switched to Qt4 instead of wxwidgets because that is what it linked against in the make file.

My question though is that the groupcoin wallet has downloaded all the blocks it says are on the chain but its still 44 hours behind.... so does this mean that a block hasnt been created for over 44 hours on the groupcoin chain?
'

[thehulkk]

is there a market where groupcoins are traded?

[IYFTech]

is there a market where groupcoins are traded?

Not that I'm aware of........yet.

[SebastianJu]

I think at the Digitalis Server of Open Transactions. Unfortunately i never was able to install the client software. Even with help for weeks. There are problems of some kind i cant solve.

[bitpop]

Use the Linux vm inside Linux

[almightyruler]

Even with RoadTrain version I get compiler error on ubuntu 13.x

SOURCE=2  -MMD -MF obj/db.d -o obj/db.o db.cpp
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -I/root/groupcoin/src -I/root/groupcoin/src/obj -DUSE_UPNP=0 -DUSE_IPV6=1 -I/root/groupcoin/src/leveldb/include -I/root/groupcoin/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF obj/init.d -o obj/init.o init.cpp
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
make: *** [obj/init.o] Error 4

Are you on a memory limited VPS? Try adding more (or any) swap.

https://www.digitalocean.com/community/articles/how-to-add-swap-on-ubuntu-12-04

[nibyokwy]

where can I sell or buy these?

[nibyokwy]

i've come across what looks like a discrepancy between the old client and the new client. if I use vanitygen to generate the address (using vanitygen -X 3 2) I sometimes get an address that is valid in the old client but not in the new one. i use 'groupcoind validateaddress' to check if it is valid. any thoughts on what the problem could be?

[markm]

Does this apply to the daemons?

As I recall there is an input verification in the GUI that one needs to change to make address in the GUI work right, when we first made GRPcoin and DVCcoin we discovered that.

Other than that well maybe compare the code of the two versions see if they treat addresses differently?

-MarkM-

[nibyokwy]

Does this apply to the daemons?

it's the daemons, yes. unfortunately I'm not a programmer so can't tell what might be wrong.

[nibyokwy]

difficulty seems to have jumped hugely the last day or two. it's now larger than i0coin. has it been picked up by other big pools or is it being traded on an exchange?