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

[chaosagent]

I was few thousand blocks from syncing the whole chain yesterday after 5 days of downloading and huntercoin crashes and the blkindex got corrupted D:

Is there something like bitcoind's -reindex i could use to repair it?

BTW, the debug.log says that a lot of blocks have too little work, which seems weird for a database corruption...

PS: I just noticed I still have 100 HUCs from back when they were a dollar a piece D:

[1714180433]

1714180433

[1714180433]

1714180433

[1714180433]

1714180433

[1714180433]

1714180433

[1714180433]

1714180433

[Want to Try]

...
My New Baby was Born on Saturday[/size] <3 [/sup][/sub]

Congratulations & Blessings for the Newborn ! Will be a Hunter for sure !

Having a kid is quite higher a priority.

[domob]

... maybe i`ll soon install it, but not before you make a lite-wallet guys!

Can somebody provide a partial bootstrap to speed startup?

fwiw a 10gb download where I live costs about $100 but the coin has long term potential so I will try.

We had one on chain.huntercoin.org until the hosting expired (was paid for someone from the community).  We now have a new server there, but it is still syncing itself.  I'll set up a download as soon as it is ready.

[domob]

Is there something like bitcoind's -reindex i could use to repair it?

I don't think as far as I know.  (You can recreate game.dat, utxo.dat and nameindex.dat if they get corrupted by simply deleting them.  I don't think this works for blkindex.dat, though.)  The new client based on latest Bitcoin code will, of course, have -reindex.  It still takes a long time to do, though.

[chaosagent]

Is there something like bitcoind's -reindex i could use to repair it?

I don't think as far as I know.  (You can recreate game.dat, utxo.dat and nameindex.dat if they get corrupted by simply deleting them.  I don't think this works for blkindex.dat, though.)  The new client based on latest Bitcoin code will, of course, have -reindex.  It still takes a long time to do, though.

Oh, okay.

I have a server that's almost synced (200k blocks away) so I'll put up a temporary download if it finishes before your server.

(The only thing you need to download to bootstrap is blkindex.dat and blkxxxx.dat right?)

Also, my server is running bdb-5.1 but my desktop has 5.3 and it refuses to load the blockchain so I am very sad

Also also, I would be willing to help with Huntercoin development (if I get some time to that is) (Yes I do sound like a n00b... I haven't touched crypto in like half a year and forgot p much everything, and I'm currently too busy to refigure it all out)

[domob]

I have a server that's almost synced (200k blocks away) so I'll put up a temporary download if it finishes before your server.

I suggest to always stop the daemon from time to time and create a backup copy of the data directory.  This way, you can be sure that you don't have to fully sync from scratch when it crashes.

(The only thing you need to download to bootstrap is blkindex.dat and blkxxxx.dat right?)

Please also include utxo.dat, game.dat and nameindexfull.dat.  As I wrote above, they can be recreated if missing, but this process itself takes quite some time.  So for a "quick" bootstrap, you have to add them as well.

Also also, I would be willing to help with Huntercoin development (if I get some time to that is) (Yes I do sound like a n00b... I haven't touched crypto in like half a year and forgot p much everything, and I'm currently too busy to refigure it all out)

This is always very welcome, best get in touch with snailbrain!

[chaosagent]

http://104.236.133.65/hucstrap/
Here're some bootstrap files
They were made using berkeleydb 5.1, so it might not work with the windoze wallet though (IDK but usually people use 4.8 or something like that on windoze)

[BayAreaCoins]

... maybe i`ll soon install it, but not before you make a lite-wallet guys!

Can somebody provide a partial bootstrap to speed startup?

fwiw a 10gb download where I live costs about $100 but the coin has long term potential so I will try.

We had one on chain.huntercoin.org until the hosting expired (was paid for someone from the community).  We now have a new server there, but it is still syncing itself.  I'll set up a download as soon as it is ready.

Sorry about her going tits up and it was a pleasure working with you Domob.

Best of luck !

[chaosagent]

The Unity3D client is constantly trying wrong passwords against my daemon (which is running on another server), even though i copied the password directly from my conf file. Any ideas?

EDIT: Changing the port, rpcuser, and rpcpassword repeatedly seems to have fixed the problem... Who said trying things over and over again even if they don't work is a bad idea?

[Fur-Coin]

Having issues installing on linux ubuntu 12.0.4

says cannot find ANYTHING in src?

done the tut 5 times to the pixel...

help?

[forzendiablo]

seems this died.. sadly.

was good idea, but got killed and trades nowhere.

[no-ice-please]

seems this died.. sadly.

was good idea, but got killed and trades nowhere.

A lot of whining lately but still one of the best coins.

If the blockchain gets shrunk somehow this will be one of the top cryptocurrencies.

[chaosagent]

seems this died.. sadly.

was good idea, but got killed and trades nowhere.

A lot of whining lately but still one of the best coins.

If the blockchain gets shrunk somehow this will be one of the top cryptocurrencies.

At a glance, HUCs decline seems to have been because of the blockchain and the bot that monopolized the center of the map (and possibly other places), which probably drove most of the players away. HUC has been my favorite cryptocurrency from day 1 of its release and still is

I really do miss the days when HUCs were a dollar per coin and each hunter only costed 1 coin, so that you could make ROI on a general and his team by just picking 2 coins off the ground... (3 hunters/general was really nice too...)

[MithrilMan]

game mechanics moved on and i don't think we can compare with the past, too many different aspects to consider (tbh i agree on some point raised about 1 huc cost)

problems are well known, blockchain size, game cost (caused even because of some bad game mechanics choices) and lack of playerbase (that can be seen both as a cause of problems and as a consequence of other problems)
i would add even the difficulty to setup all the needed things in order to play

Before vacations i gave some advice about game mechanics/features changes/additions and I'm waiting that the subject is taken into consideration to start implementing something over it
Lately there has not been much development around the project (not talking just about client(s) implementations but about the currency as a whole, like services based on HUC, etc...) and this of course doesnt' help the coin/game

personally i'm going to release a new version of my client soon, but i can just work on existing rules and official daemon (huntercoind.exe) so i can't resolve blockchain problems or game mechanics changes, i can help on easing installation and time saving (using automatic behaviours and alert systems i've already implemented and improved in the upcoming release) and trying to build up some market around the game (the idea of creating custom content and custom automatic behaviours and let the players sold them on a market) but we need a shake.

Now that Snailbrain has become a father he will have even less time to dedicate, I know, I've a little daughter 1.6f (nerd style floating point age ) years old, even if I'm a little insane and i spend almost all of the sleepless night coding my client, but i hope for his sanity to spend more time sleeping than me

having said that, the problem is that the project can't go on without a strong community effort or a strong leadership
Without a public project plan with milestones, etc... would even be hard to collect some income to speed up development (I'm not talking about the development on my side but on huntercoin core development)
At first, crypto momentum and huntercoin novelty helped collecting some donation and help, but now it would be harder without something to show, to believe

I think we need to face all these problem and try to fix them, otherwise the project will keep to drift

about stated problems, talking about blockchain size I know Domob in recent months started to port new bitcoin codebase in namecoin and planning to port then in huntercoin, and then hopefully he'll have a base to work on an effective pruned light wallet.
I don't know the time that would be needed to see the pruned thing, i think a lot, anyway i think that the development (in term of planned features, in-progress implementation, ETAs, etc...) should be always publicly accessible and always up-to-date because updated informations, ETAs, etc... are the key to modern marketing and a basic and required ingredient for a successful project like this that has no marketing power ($$) to see a boosted development and so must be fueled by the community

P.S.
Is not a programmer duty to keep the community updated, someone dedicated has to play that role

On my side, about my custom client, i'm playing a "one man development" and I clearly see that i fail in some aspect because i don't have the time to cover all (talking i.e. about my client, multilanguage guide, detailed changelog release, publishing screens/video, talking about upcoming changes, explaining tips and techniques, etc...) but at least my responsability is limited on my side project, that can impact relatively on huntercoin success, but the main project should be handled in the proper way

look out of here, there are even lot of "shitcoins" that have lot of informative content and updated infos (their problem is most of the time the fact that they don't add anything interesting on the technical side of the project), I think this is an aspect that need to be improved

[domob]

about stated problems, talking about blockchain size I know Domob in recent months started to port new bitcoin codebase in namecoin and planning to port then in huntercoin, and then hopefully he'll have a base to work on an effective pruned light wallet.
I don't know the time that would be needed to see the pruned thing, i think a lot, anyway i think that the development (in term of planned features, in-progress implementation, ETAs, etc...) should be always publicly accessible and always up-to-date because updated informations, ETAs, etc... are the key to modern marketing and a basic and required ingredient for a successful project like this that has no marketing power ($$) to see a boosted development and so must be fueled by the community

Actually, the Namecoin port is long finished and the Huntercoin port is not only planned but progressing very well.   I do not have any ETAs or a roadmap, but at least the up-to-date implementation can be found on https://github.com/domob1812/huntercore/ at any moment.  It is already able to sync the full blockchain and to serve game_getstate calls.  It is also able to prune the blockchain based on Bitcoin's feature, which according to some tests snailbrain did reduce the blockchain size to something like 1.5 GiB.  Even less may be possible in the future with some more tuning of parameters.

Note, however, that the new client does not yet handle the wallet well (game transactions won't show up), nor can it be used for mining.  These are the next steps for me, but I'm currently in the process of finishing my PhD thesis (which has way higher priority).

[MithrilMan]

about stated problems, talking about blockchain size I know Domob in recent months started to port new bitcoin codebase in namecoin and planning to port then in huntercoin, and then hopefully he'll have a base to work on an effective pruned light wallet.
I don't know the time that would be needed to see the pruned thing, i think a lot, anyway i think that the development (in term of planned features, in-progress implementation, ETAs, etc...) should be always publicly accessible and always up-to-date because updated informations, ETAs, etc... are the key to modern marketing and a basic and required ingredient for a successful project like this that has no marketing power ($$) to see a boosted development and so must be fueled by the community

Actually, the Namecoin port is long finished and the Huntercoin port is not only planned but progressing very well.   I do not have any ETAs or a roadmap, but at least the up-to-date implementation can be found on https://github.com/domob1812/huntercore/ at any moment.  It is already able to sync the full blockchain and to serve game_getstate calls.  It is also able to prune the blockchain based on Bitcoin's feature, which according to some tests snailbrain did reduce the blockchain size to something like 1.5 GiB.  Even less may be possible in the future with some more tuning of parameters.

Note, however, that the new client does not yet handle the wallet well (game transactions won't show up), nor can it be used for mining.  These are the next steps for me, but I'm currently in the process of finishing my PhD thesis (which has way higher priority).

this is indeed a good news!
about saying to see https://github.com/domob1812/huntercore/ this is the problem, huntercoin news, etc... should be accessible to anyone, not just programmers or geeks (again, I'm not blaming you! )

personally i'm be interested about knowing more on the pruning implementation, how is it achieved?
does exists some informative link i can read about it?
will the blockchain always reduce at that size even in future or is just a % of the total size?
what will be the impact when more players will join and so generate lot of transactions per block?

Ideally would be nice to have fixed blocks (like every 1440 blocks that mean every day, or even a week) that generate a kind of "snapshot" that could be used as a new genesis block everytime with a block that contains all unspent inputs, would this be ever an option for the future?

P.S.
good luck about your PhD thesis!

[no-ice-please]

There are a few things that give Huntercoin an edge over most coins and a few reasons why it is so low right now.

The biggest positive is the way coins are mined. It will have a sort of 'automatic community' of users once cryptos rebound. Other coins will copy and adapt the 'human mining' idea but Huntercoin was the first and has a small group of people with the most experience.

The biggest negative is the overwhelming difficulty a new user has in simply getting started. If you send a hundred people to bitcoin almost all of them will be able to figure it out and get started within a day. If you send a hundred people to Huntercoin fewer than five out of a hundred people without technical experience will be able to figure it out.

Possibly the best coin out there.

But still needs work.

[chaosagent]

There are a few things that give Huntercoin an edge over most coins and a few reasons why it is so low right now.

The biggest positive is the way coins are mined. It will have a sort of 'automatic community' of users once cryptos rebound. Other coins will copy and adapt the 'human mining' idea but Huntercoin was the first and has a small group of people with the most experience.

The biggest negative is the overwhelming difficulty a new user has in simply getting started. If you send a hundred people to bitcoin almost all of them will be able to figure it out and get started within a day. If you send a hundred people to Huntercoin fewer than five out of a hundred people without technical experience will be able to figure it out.

Possibly the best coin out there.

But still needs work.

The most obvious solution I could think of right now for the blockchain syncing problem is 'start-in-the-middle' syncing, where you would get the gamestate and  block of a specific block (say, multiples of some moderate number) from several different peers with the most blocks and using that data to come to a consensus on what the gamestate at the block is, and syncing from there while discarding previous gamestates. This might be improved by having a 'gamestate-recording' block every couple thousand blocks that contains the full gamestate so there is at least some proof-of-work in place to verify the gamestate. This improvement might also have the side-effect of mitigating the problem of orphan chains in a client that doesn't hold the whole blockchain.
(I'm assuming that all blocks just hold whatever moves were made during the block like a diff)

I don't really know, but this seems like an okay idea to me rn, but there's probably some stupidly obvious flaw and I need more sleep.

Of course, a centralized server that has the entire blockchain and allows more multiple different people to plug in a client and play would work too, but that puts too much trust in the server...


Of course, the biggest problem with any of this is the lack of developer time, which makes a kind of a dependency cycle...

[no-ice-please]

The most obvious solution I could think of right now for the blockchain syncing problem is 'start-in-the-middle' syncing, where you would get the gamestate and  block of a specific block (say, multiples of some moderate number) from several different peers with the most blocks and using that data to come to a consensus on what the gamestate at the block is, and syncing from there while discarding previous gamestates. ...

...Of course, a centralized server that has the entire blockchain and allows more multiple different people to plug in a client and play would work too, but that puts too much trust in the server...


Of course, the biggest problem with any of this is the lack of developer time, which makes a kind of a dependency cycle...

I honestly don't know any of the technical side, so am not in a position to say if that is possible. It sounds practical.

Lack of developer time is only important if you are in a rush. The core developers will spend extra time they have after family, job etc when they feel like it. At this point cryptos are a hobby for everyone, including developers, and not a vocation. Once the rebound occurs and the coins people are holding for hobby are worth more than the company they work for, then it will be their job.

Til then devs shouldn't stress.

[MithrilMan]

The most obvious solution I could think of right now for the blockchain syncing problem is 'start-in-the-middle' syncing, where you would get the gamestate and  block of a specific block (say, multiples of some moderate number) from several different peers with the most blocks and using that data to come to a consensus on what the gamestate at the block is, and syncing from there while discarding previous gamestates. This might be improved by having a 'gamestate-recording' block every couple thousand blocks that contains the full gamestate so there is at least some proof-of-work in place to verify the gamestate. This improvement might also have the side-effect of mitigating the problem of orphan chains in a client that doesn't hold the whole blockchain.
(I'm assuming that all blocks just hold whatever moves were made during the block like a diff)

I don't really know, but this seems like an okay idea to me rn, but there's probably some stupidly obvious flaw and I need more sleep.

Of course, a centralized server that has the entire blockchain and allows more multiple different people to plug in a client and play would work too, but that puts too much trust in the server...


Of course, the biggest problem with any of this is the lack of developer time, which makes a kind of a dependency cycle...

this is similar to what i said 2 post above when i said:

Ideally would be nice to have fixed blocks (like every 1440 blocks that mean every day, or even a week) that generate a kind of "snapshot" that could be used as a new genesis block everytime with a block that contains all unspent inputs

you just forget to mention about the wallet addresses problems and this is why i talked about unspent inputs, that are all the inputs (coins) that are available at a current block height (and since hunters under the hood are addresses, even hunters are in)
I don't think that moves are updated on blockchain every block, so if you set a path that takes 1000 blocks to reach its destination and you take only last 500 blocks, his move will be lost
To overcome this problem should be implemented a rule that generate a 0 cost name_update transaction (if possible) that contains the delta of the remaining move
Consider even that the snapshot should be generated at a specific block but after that the "consensus threshold" has been passed (actually when you wait a game_reward, you have to wait 120 blocks for the consensus, to prevent blockchain reordering issues)

Well, i don't want to dive into too technically explainations but I think that the snapshot idea is good and has just to be done right ( )

about centralization system, even there the wallet part is a problem, except if you want to host your addresses to that server (trust problem)

Of course, the biggest problem with any of this is the lack of developer time, which makes a kind of a dependency cycle...

That's the main problem, no other crypto developers are involved except domob and coding for huntercoin isn't his daily job
Would be interesting seeing other devs join to help, sourcecode is public on github and anyone can fork, implement and pull-request