[ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain

[BGB_HUC]

I'm planning to update the chain download on http://chain.huntercoin.org/ to a current one.  I would also like to use the new nameindex pruning on it.  Are there any objections to this?  This will probably require users to have the current version installed, otherwise weird things may happen.  Also, using the pruned chain, it won't be possible to use the "name_history" command to show history back to genesis.  If you want to do that for whatever reason, you have to sync yourself - but I think that's fine, since this is nothing new players want to do anyway.

So:  Is everyone fine with updating to a pruned chain download during the next week or so?  Please let me know now if you think I should wait with this a little longer.

would be possible to add some info into the blockchain, like the last client version that generated it, in order to prevent someone from using a wrong client version?
i mean that if your write the current client version into blockchain in future client release, it would be possible to do that check

about your question i think it's better this time to have the old version, in case the new one has problems/bugs, doesn't sounds fine?

Maybe the client files that are needed for that version could be included in the tar or the web page (for non wget users) would specify what version of the client is needed?

[MithrilMan]

I'm planning to update the chain download on http://chain.huntercoin.org/ to a current one.  I would also like to use the new nameindex pruning on it.  Are there any objections to this?  This will probably require users to have the current version installed, otherwise weird things may happen.  Also, using the pruned chain, it won't be possible to use the "name_history" command to show history back to genesis.  If you want to do that for whatever reason, you have to sync yourself - but I think that's fine, since this is nothing new players want to do anyway.

So:  Is everyone fine with updating to a pruned chain download during the next week or so?  Please let me know now if you think I should wait with this a little longer.

would be possible to add some info into the blockchain, like the last client version that generated it, in order to prevent someone from using a wrong client version?
i mean that if your write the current client version into blockchain in future client release, it would be possible to do that check

about your question i think it's better this time to have the old version, in case the new one has problems/bugs, doesn't sounds fine?

Maybe the client files that are needed for that version could be included in the tar or the web page (for non wget users) would specify what version of the client is needed?

but what i asked was an automatic check that the client can do in order to not broke a blockchain generated by a newer version.
an rpc command that return current version would be useful too (for 3rd party clients like mine)

e.g. a client can check if the blockchain is marked with a tag saying it has been generated by version X. if X < current version it's fine and the client can use it and update, if X>currentVersion then an error popup saying to update the client to the latest version

of course this check should be added to the next client version and will be usefull from further next

[billybob2014]

No I'm talking about before the disaster, most of my guys were  not far from home then disaster hit..  The bots then scooped up their coins after they died.   Like I said I dont care about that cause I'm way ahead, but if it was my first time playing and I just invested to create these characters I probably wouldn't be happy.  Just dont think the disaster in its current form really does anything positive for humans.

It's not worthy of remembering little coins lost in disaster in several days. You can  hold  more than 10 pools if you have time, which can produce nearly 500-1000 coins for one day, that is advantage of human over bots.

BGB got a 1000 or 2 (maybe he can say the exact amount) just by being first in line after a disaster.  And that was just around the edges.  I just think the disaster serves bots even more than before if it is like this.   I dont want to seem like I'm complaining or jealous.  I have bought a shitload of HUC, and play for fun.  Just want to help make it better and make suggestions so that they become more valuable in the future.

[MithrilMan]

meanwhile a disaster is just happening
while a fight blue vs yellow was going on in the middle lol

[billybob2014]

meanwhile a disaster is just happening
while a fight blue vs yellow was going on in the middle lol

Dammit not home lol

[BayAreaCoins]

No I'm talking about before the disaster, most of my guys were  not far from home then disaster hit..  The bots then scooped up their coins after they died.   Like I said I dont care about that cause I'm way ahead, but if it was my first time playing and I just invested to create these characters I probably wouldn't be happy.  Just dont think the disaster in its current form really does anything positive for humans.

It's not worthy of remembering little coins lost in disaster in several days. You can  hold  more than 10 pools if you have time, which can produce nearly 500-1000 coins for one day, that is advantage of human over bots.

BGB got a 1000 or 2 (maybe he can say the exact amount) just by being first in line after a disaster.  And that was just around the edges.  I just think the disaster serves bots even more than before if it is like this.   I dont want to seem like I'm complaining or jealous.  I have bought a shitload of HUC, and play for fun.  Just want to help make it better and make suggestions so that they become more valuable in the future.

I can totally see where a disaster would favor the bots with the speed of launching new players.

Kinda like how you aren't home right now!

[justbtcme]

Checking in guys. Never heard of huntercoins until recently. What are some good things going for it?

[snailbrain]

Some stuff about disaster - it wasn't supposed to remove bots... we can never remove bots - which is why we need to make play more automated and semi-afk'able - (more like an RTS - e.g. send your hunter to a harvest field and he will return and go back, auto attack, guard -- basic botting)

There were a few reasons for disaster..

Reduce Population (afk players etc) - the amount of hunters on the map was something like 50k - many tx, blockchain size increasing more rapidly.
to add a random risk to losing all hunters (not cost effective to control 10000000 hunters), -- The reason for not having a specific time for a disaster was so that Bots cannot create 10000000000 hunters, then recycle before the disaster happens.
Recuce Bot to Human Ratio - has definitely reduced.
Help with pruning (don't think domob needed to take advantage of it though )
Increase to cost of play and add risk.
and more but would need to check...

About bots starting when disaster happens.. we already thought and said that would happen before we implemented it (written on forum somewhere).
It's an issue, but I think it's not as bad as it seems. In reality they can only guarantee get the easy coins in their own quadrant. The rest is up for grabs if you have enough and can attack.
Open to ideas..
One solution was that you maybe spawn in random locations for the next X blocks after disaster -- it may make the easy coins harder to get (if you start on the opposide side of your normal spawn area for 100 blocks?)..  not sure if a good idea - needs more thought.

What we need
Get more players
Post suggestions in the development section on http://forum.huntercoin.org with any ideas to improve
Donate to Domob while he works on implementing blockchain pruning so people can instant download the chain, will be perfect for MithrilMan Client.
Make / Donate for someone to do a GUI on top of Domob's > Huntercoin python botting framework http://forum.huntercoin.org/index.php?topic=139.0 - will give a bounty
Report Issues on forum
Await Huntercoin Client on Android/IOS - in development.

p.s. anyone tried name_clean yet?

[BayAreaCoins]

Checking in guys. Never heard of huntercoins until recently. What are some good things going for it?

The thing I find most interesting about HUC is the way the coins are distributed and the security of the network using both SHA-256 & SCRYPT both of which are merge mined.

I think that the next trend of coin will attempt to copy Huntercoin in the way the coins are spread around to the users.  Basically with HUC you can become a miner with only a lap top and a internet connection. (soon to be just a smart phone/tablet/ect)

This is literally the only decentralized work place where Jews/Muslims/Christians can work side by side and still blow each other up without making the national news (thus far any ways.... who knows what is to come!)

[bigminner]

About bots starting when disaster happens.. we already thought and said that would happen before we implemented it (written on forum somewhere).
It's an issue, but I think it's not as bad as it seems. In reality they can only guarantee get the easy coins in their own quadrant. The rest is up for grabs if you have enough and can attack.
Open to ideas..
One solution was that you maybe spawn in random locations for the next X blocks after disaster -- it may make the easy coins harder to get (if you start on the opposide side of your normal spawn area for 100 blocks?)..  not sure if a good idea - needs more thought.

Agree.  Actually more than 90% coins on map are captured by human, not by bots. But the price still not rise even human dominate the map. I think the price has no relation to how many coins are captured by human compared to bots.  And open bot library has released by dev team, every one can use it. But if you want a more powerful bot, you need to write many lines of algorithm, which is more hard work than playing this game by hand.  
The price of HUC is related to difficulty of playing(more players leads to more competing and difficulty), application, and capital investment. Now the pruning of nameindexfull.dat has worked successfully, the pruning of block chain is on the way.  If the pruning and wallet stuck of pending are solved(still not solved in 1.011g), there will be more players in this game.

[jwinterm]

If the pruning and double spending are solved(still not solved in 1.011g), there will be more players in this game.

double spending?

[bigminner]

If the pruning and double spending are solved(still not solved in 1.011g), there will be more players in this game.

double spending?

It is the wallet stuck of spending(sometimes shows "spending rejected"), not double spending of the whole system.

[snailbrain]

If the pruning and double spending are solved(still not solved in 1.011g), there will be more players in this game.

double spending?

It is the wallet stuck of spending(sometimes shows "spending rejected"), not double spending of the whole system.

have you tried name_clean?

the double-spend btw, this isn't some hack that allows people to spend coins twice, as it may sound. Some people have hunters which get stuck..
If you get the pending problem, use name_clean

none of the patches make a difference to the pending problem (nothing automatic) - you need to manually attempt to fix with name_clean (this rpc has been updated to attempt to fix stuck pending players)

give us feedback - this patch has been out for a long time and not one person has said whether it works or not (or i've missed it)

If it works, Domob can allow it to run in some sort of automated fashion

[bigminner]

If the pruning and double spending are solved(still not solved in 1.011g), there will be more players in this game.

double spending?

It is the wallet stuck of spending(sometimes shows "spending rejected"), not double spending of the whole system.

have you tried name_clean?

the double-spend btw, this isn't some hack that allows people to spend coins twice, as it may sound. Some people have hunters which get stuck..
If you get the pending problem, use name_clean

none of the patches make a difference to the pending problem - you need to manually attempt to fix with name_clean.

give us feedback - this patch has been out for a long time and not one person has said whether it works or not

If it works, Domob can allow it to run automatically.

I  have tried name_clean( return true after command), but pending still exists. I have uploaded some wallets stuck of pending to domob, he will check them.

[MithrilMan]

FYI, I've just found that my bot wallet i left running to test my bot interface now has pending transactions, when I'll have time I'll try name_clean, etc...
now I'm @ work and can't do that

[MithrilMan]

@snailbrain forget to say:

I downloaded latest version (11g)
i had deleted some pending transaction before installing it
then i installed, run my client and the daemon where stuck at stage "reaccepting wallet transactions"

after a while i restarted the daemon and in degub log it says InvalidChainFound

ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
InvalidChainFound: invalid block=bc301272d8e00c26632a  height=346023  work=206931702201427835251197
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : ConnectBlock failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 9fdad33fd0853f39b6ec
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f8077f0, pnext=00000000, nFile=4, nBlockPos=2093386035 nHeight=346024, merkle=1e7bf626a7, hashBlock=9fdad33fd0853f39b6ec)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=9fdad33fd0853f39b6ec  height=346024  work=206931767448775230994941
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
connected 192.210.135.154:8398
received block 50c4bf3f81b1328bc188
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f807900, pnext=00000000, nFile=4, nBlockPos=2093388707 nHeight=346025, merkle=2b3f4fac17, hashBlock=50c4bf3f81b1328bc188)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=50c4bf3f81b1328bc188  height=346025  work=206931832645508852967933
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 51c80e9170f1a61925c1
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f807878, pnext=00000000, nFile=4, nBlockPos=2093394648 nHeight=346026, merkle=8757b60982, hashBlock=51c80e9170f1a61925c1)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!

it was repeating this message continuously in debug.log, nonstop, so i restarted again and at this point i get a Runaway exception in debug.log:

EXCEPTION: NSt8ios_base7failureE      
ReadCompactSize() : size too large      

previous debug line was "refreshWallet"

[MithrilMan]

update: i used a backup, left it running without interrupting it, and it keep giving errors in debug.log, still not able to use it during REORGANIZE:

REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1a2d5230, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1e9ffee0, pnext=00000000, nFile=4, nBlockPos=2093906621 nHeight=346125, merkle=461a3f4790, hashBlock=75fe44df718000785fb2)
  Common: CBlockIndex(nprev=1a2d5230, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=75fe44df718000785fb2  height=346125  work=207112889955601132511996
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
InvalidChainFound: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 245133d97f0c10008952

it seems it's not accepting blocks, don't know, and i don't understand why it says "InvalidChainFound: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."


I've to say, as a note, that my previous version wasn't the 11f i think, so i don't know if it's actually important to upgrade from a version to the next one, without jumping to the last (if it's the case, it's a problem..)

anyway at the moment i can't play at all, even if i used my backup (so maybe later i'll downgrade my daemon)

[BGB_HUC]

p.s. anyone tried name_clean yet?

I have not had any luck with clearing the pending transactions I have been getting. I had some double spends and stuck characters from the disaster yesterday. I have two green characters that I have not been able to revive trying everything I am aware of.

They appear in name_pending RPC with waypoints, but will not move.

[domob]

@MithrilMan:  No, you need not upgrade from one version to the next.  The error you are getting sounds like a corrupted utxo.dat.  Try shutting down the client, removing utxo.dat and restarting.  This will recreate it - but it takes a long time.  Alternatively, you can try to revert to my blockchain download or a backup (but only if you know that the backup it clean).

Regarding the pending issue:  Thanks to bigminner, I looked at some wallets that indeed showed strange behaviour.  This is most probably "only" an issue with relaying / mining the transactions, not the double-spending one.  (The latter is still actually possible when hunters get killed and you have to clear transactions of them, and it should be fixed by "name_clean".)

I've got a suspicion about what the problem is, and have written a small patch that gives extended debug log to test it.  It takes some time for my VPS to fill its mempool, though, so I can't know for sure right now.  Hopefully in some time.

In short, I suspect that the problem is that if you "deletetransaction", then this only removes the tx from your own node.  If others still have it in the mempool, this is not cleared.  When you then try to re-create the tx, it is considered a double-spend and not relayed / mined.  Maybe it is even a combination of both problems:  The initially stuck transaction is created due to the already stated double-spending issue (player death).  You can fix it locally for yourself by deleting the transaction (or letting "name_clean" delete it for you), but other nodes don't delete the tx even though it can never confirm anymore.  You also can't respend the coins, since the other nodes block it.

If this suspicion is confirmed, the fix should be to make "name_clean" (or an equivalent action) be performed automatically on the mempool by all nodes - then, when every relaying node plus miners upgrade, it should prevent this from happening again.

[MithrilMan]

@MithrilMan:  No, you need not upgrade from one version to the next.  The error you are getting sounds like a corrupted utxo.dat.  Try shutting down the client, removing utxo.dat and restarting.  This will recreate it - but it takes a long time.  Alternatively, you can try to revert to my blockchain download or a backup (but only if you know that the backup it clean).

I tried recreating utxo.dat too, and it crashed at some point with the error "ReadCompactSize() : size too large"
now i'm at home and will put my chain on ssd and tomorrow will try again on that pc to see if maybe it could have some HW problem about the disk

Regarding the pending issue:  Thanks to bigminner, I looked at some wallets that indeed showed strange behaviour.  This is most probably "only" an issue with relaying / mining the transactions, not the double-spending one.  (The latter is still actually possible when hunters get killed and you have to clear transactions of them, and it should be fixed by "name_clean".)

I've got a suspicion about what the problem is, and have written a small patch that gives extended debug log to test it.  It takes some time for my VPS to fill its mempool, though, so I can't know for sure right now.  Hopefully in some time.

In short, I suspect that the problem is that if you "deletetransaction", then this only removes the tx from your own node.  If others still have it in the mempool, this is not cleared.  When you then try to re-create the tx, it is considered a double-spend and not relayed / mined.  Maybe it is even a combination of both problems:  The initially stuck transaction is created due to the already stated double-spending issue (player death).  You can fix it locally for yourself by deleting the transaction (or letting "name_clean" delete it for you), but other nodes don't delete the tx even though it can never confirm anymore.  You also can't respend the coins, since the other nodes block it.

If this suspicion is confirmed, the fix should be to make "name_clean" (or an equivalent action) be performed automatically on the mempool by all nodes - then, when every relaying node plus miners upgrade, it should prevent this from happening again.

this makes sense about the deletetransaction and you could be right about that problem, but why it should stay at no confirmation state at first place even if i don't call deletetransaction?
maybe the system call deletetransaction or some equivalent on other transactions that share one of the input that the killed player transaction had?

since the stuck problem doesn't seems to happen everytime (or at least i think), maybe the problem is that there is something that goes wrong where 2 transaction share one of the input address?