Topic: [RE-ANN] Galaxycoin Revival! KGW, POS/POW hybrid [TRADING ON CRYPTSY] - page 17. (Read 51810 times)

Is there any exchange on the new fork?

Yep, spot on. Thanks for giving the command, am seeing an 80% orphan rate.

Am not used to seeing the rate of orphans this high, it's usually the other way around. Suspect it may be down to general network latency combined with my low hashrate.

EDIT: I am based in Australia so this is no surprise TBH

That sounds like an orphan, where someone else has found a block at almost exactly the same time as you did. Only one miner can win.

If you do 'listtransactions' in the debug console you should be able to see the orphaned blocks.

Hi there, am having a go at soloing GLX while the diff is low. However my QT client is acting somewhat strangely. It has recorded three transactions and yet has a balance of zero with no unconfirmed coins to be seen. I know I have processed blocks as I have three of these events in my logs:
These blocks may have been orphaned but my transaction log is empty. Does anyone know what might be up?
I am using Galaxycoin version 2.0.0.0 with SGminer 4.1.0 in a Win7 64bit environment.

EDIT
OK, weird. I just saw a new block get accepted and received the notification that I had received 64 GLX. This updated the 'Unconfirmed' entry in my wallet with the 64 GLX, but then this went back to zero in 2 secs. Balance not updated.

So much better than:

0.02
20.1
8.7
0.05
30.0

and etc...

Even with KGW it is a rollercoaster...

0.60912927
0.30456464
0.15228232
0.07614116
0.03807058
0.01903529
0.00951764
0.00475882
0.00237941
0.00118971
0.00059485
0.00097517
0.00171084
0.0032901
0.0065802
0.0131604
0.0263208
0.0526416
0.1052832
0.21056639
0.42113279
0.69801253

... and the cycle repeats ...

My ticket hasn't updated yet but you never know. Go ahead a try a small test transaction.

Anyone hear back from Cryptsy yet about progress on updating? I know it's not something they're very good about.

I see the network starting to lose some steam, hopefully we can get this trading soon

Why would you want the DIFF to jump from 0.5 to 20 like it used to?

Other than to screw over the solo and pool miners?

Link: https://mega.co.nz/#!7wxziYSa!kA0RUpyT04spvzpwxLKp7-a6v6npsEMhNYmEhMXVmro

Merry Christmas.

Also, information on syncing:

Galaxy was good to me , if you fixed the funky diff jumping I'm not playing.  : |

that was both funny and fun.

I will give a bounty of 20 coins to anyone that can send me the windows wallet to [email protected]

Yep, I emailed them about it

Hey, Coinwarz found about our fork,
http://prntscr.com/31zva3

Yup something we've experienced before mate and see it happen over and over again , also suggested increasing the number of nodes with new wallets so the the new chain will take over. 51% attack literally.

~Soopy~

I'm having a lot of problems with clients on the older fork. There seems to be a fundamental bug in *coin code (not just GLX) where if there is a fork the clients on the "old" chain will repeatedly sent getblocks requests, asking for the same set of blocks, in an endless loop. It never stops. This consumes CPU and (in my case, more significantly) bandwidth.

I've had to resort to firewalling peers showing a height of 250k.


[
{
"addr" : "71.4.209.204:15521",
"services" : "00000001",
"lastsend" : 1395113582,
"lastrecv" : 1395113582,
"conntime" : 1395112041,
"version" : 60008,
"subver" : "/Satoshi:2.0.0/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 258911,
"banscore" : 0
},
{
"addr" : "37.59.21.199:15521",
"services" : "00000001",
"lastsend" : 1395113583,
"lastrecv" : 1395113583,
"conntime" : 1395112042,
"version" : 60008,
"subver" : "/Satoshi:2.0.0/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 258911,
"banscore" : 0
},
{
"addr" : "193.37.138.34:15521",
"services" : "00000001",
"lastsend" : 1395112958,
"lastrecv" : 1395112089,
"conntime" : 1395112074,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "109.197.13.54:15521",
"services" : "00000001",
"lastsend" : 1395112581,
"lastrecv" : 1395112958,
"conntime" : 1395112240,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "67.210.249.29:15521",
"services" : "00000001",
"lastsend" : 1395112580,
"lastrecv" : 1395112273,
"conntime" : 1395112264,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "85.25.194.85:15521",
"services" : "00000001",
"lastsend" : 1395112580,
"lastrecv" : 1395112370,
"conntime" : 1395112364,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "144.76.33.10:15521",
"services" : "00000001",
"lastsend" : 1395112580,
"lastrecv" : 1395112368,
"conntime" : 1395112365,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "162.243.225.236:15521",
"services" : "00000001",
"lastsend" : 1395112582,
"lastrecv" : 1395112490,
"conntime" : 1395112476,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "101.165.152.2:15521",
"services" : "00000001",
"lastsend" : 1395112584,
"lastrecv" : 1395112551,
"conntime" : 1395112542,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "83.167.82.18:15521",
"services" : "00000001",
"lastsend" : 1395112762,
"lastrecv" : 1395112767,
"conntime" : 1395112761,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "54.201.121.142:15521",
"services" : "00000001",
"lastsend" : 1395112960,
"lastrecv" : 1395112876,
"conntime" : 1395112868,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "198.27.97.178:15521",
"services" : "00000001",
"lastsend" : 1395112975,
"lastrecv" : 1395112984,
"conntime" : 1395112974,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "202.60.68.241:15521",
"services" : "00000001",
"lastsend" : 1395112976,
"lastrecv" : 1395112992,
"conntime" : 1395112975,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "2.236.53.94:15521",
"services" : "00000001",
"lastsend" : 1395113061,
"lastrecv" : 1395113069,
"conntime" : 1395113059,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "199.193.251.112:15521",
"services" : "00000001",
"lastsend" : 1395113400,
"lastrecv" : 1395113409,
"conntime" : 1395113399,
"version" : 60008,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 250339,
"banscore" : 0
},
{
"addr" : "50.7.135.34:15521",
"services" : "00000001",
"lastsend" : 1395113532,
"lastrecv" : 1395113537,
"conntime" : 1395113532,
"version" : 60008,
"subver" : "/Satoshi:2.0.0/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 18924,
"banscore" : 0
}
]


We need more nodes with the updated client Atleast 20

Yep, hence why I suggest we hold off on purchasing GLX for now.

The trades and the transfers are different things. It shouldn't affect them
But since we talk about cyptsy... god knows.

Ok, thanks for the quick answer.