Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - domob

Pages: [1]
Development / Change to gamestate JSON format
« on: August 09, 2017, 07:11:17 PM »
We are planning to change the gamestate JSON format before the upcoming hard fork.  All front-end software that parses the game state needs to be updated, at the latest at the fork (when all users will have to update to the new version of the client).

More details:

Development / [ANN] Huntercoin Core - ready for first testing
« on: April 16, 2016, 06:26:05 PM »
After quite a long time, I think that Huntercoin Core is now ready for first "real" testing on mainnet, if you are brave enough.  I've done some tests with the character "domob", and all seemed to be working so far.  The client should be ready for playing (command-line only, so as a backend for something like Mithril or Unity), but do not use it for mining.  That will come later.  Also, of course, there may be severe bugs left that could lead to loss of coins in the extreme.

You can find my latest source at  Snailbrain reported issues compiling for Windows, which I unfortunately cannot reproduce on GNU/Linux.  It works fine for me on Debian.  Feel free to play around, and if you are able to fix the Windows issues, I'm sure snailbrain can put up a bounty for that from the development funds.

Development / Game Channels for Off-Chain Interactions
« on: October 20, 2015, 03:17:46 PM »
If you are also reading Bitcointalk, you probably already noticed my post there about a recent idea that allows for trustless off-chain interactions in Huntercoin (or, in fact, other games as well):

I've now finished writing a more elaborate description, which is available as paper manuscript at  I welcome any feedback you have!  Here's the abstract for convenience:

Blockchains can be used to build multi-player online games and virtual worlds that require no central server. This concept is pioneered by Huntercoin, but it leads to large growth of the blockchain and heavy resource requirements. In this paper, we present a new protocol inspired by payment channels and sidechains that allows for trustless off-chain interactions of players in private turn-based games. They are usually performed without requiring space in the public blockchain, but if a dispute arises, the public network can be used to resolve the conflict. We also analyse the resulting security guarantees and describe possible extensions to games with shared turns and for near real-time interaction. Our proposed concept can be used to scale Huntercoin to very large or even infinite worlds, but it also has applications beyond Huntercoin like decentralised poker games, smart contracts or a blockchain for generic private gaming.

Development / Renaming "lostCoins" to "gameFund"
« on: February 08, 2015, 11:02:04 AM »
In case anyone is using the "lostCoins" field of the game state JSON, it will be renamed to "gameFund" in the future.  Please update your code accordingly.  Apart from the renaming, nothing changes.  Since these coins may be used to fund things like NPCs in the future, the new name seems more appropriate.  Furthermore, with the planned next hardfork this fund will not just include the crown bonus from times when the crown is on the floor, but also certain coins removed from the map / players on disaster time.

I'm also going to change the JSON output of "analyseutxo" slightly, but presumably no code is using this anyway (as it is slow and mostly useful for a manual call from time to time).

Let me know if you need more details!

Development / Simpler name registration
« on: October 12, 2014, 05:30:29 PM »
As promised, I've been working on simplifying the name registration procedure (so that just a single transaction is enough to register names, as opposed to the two-step registration necessary at the moment).  The code is almost ready, but needs some more testing before I can submit it.  Here some details:

The change will be a hardfork, and probably be done together with the addition of a carrying capacity.  The "old-style" name registration will stay fully valid, but starting at the hardfork block, a "new-style" method will also be recognised.  In the new method, a NAME_FIRSTUPDATE operation can be issued directly without a preceding NAME_NEW.  It doesn't require to provide a rand/hash value, but simply register the name upon confirmation.  (The drawback is that while the transaction is pending and not yet confirmed, everyone on the network sees the name you want to register and may try to "steal" it from you - that's the reason why Namecoin has NAME_NEW.  I don't think this is an issue for Huntercoin, though, where names aren't particularly valuable.)

Also starting at the hardfork point, a new RPC call "name_register" will be available that can be used to issue new-style registrations.  name_new and name_firstupdate will stay available and will keep doing old-style transactions.  The Qt UI won't (yet) use the new methods, but this will be changed at some point after the fork.

Please let me know if you see any problems with this plan, or if you have suggestions to make!

Bounties / Donate / A "Thank You" to the brave hunters
« on: October 02, 2014, 03:36:44 PM »
Since recently, I'm receiving regular game rewards to my donation address by some brave hunters!  This is very appreciated - thank you very much! :)

General Discussion / Does anyone use "reward address lock"?
« on: September 30, 2014, 06:07:58 AM »
The client currently allows to "lock" the reward address - does anyone use this feature?  If not, are there any objections to removing that in the future?  I think this would make the code simpler and also allow for easier pruning.  (Not that it is impossible to prune without removing the lock, but if noone uses it anyway I see not really a reason not to simplify things.)

Development / Carrying capacity limit
« on: September 25, 2014, 12:17:52 PM »
It has been suggested already a couple of times to implement a maximum "carrying capacity" for characters.  Since I also believe this is a beneficial change, I've implemented a proposed patch:

What this patch does:
  • Starting from a certain hardfork point (currently set to block 1,000,000 until it is fixed), each character can only carry 100 HUC at most.
  • This limit will only be enforced when picking up new coins.  Characters holding more than the limit when the change is made won't drop the coins but can't pick up more.  At least after the next disaster there won't be any more characters with "too many" coins on then.

  • The crownholder has currently no limit.  However, the code is written in such a way that it is possible to impose the limit also there.  In that case, coins earned by the crown that can not be carried will be destroyed similarly to the crown bonus that is destroyed when no-one is holding the crown at the moment.

Please test (see the pull request for some details on how to do it) and discuss! :)  Questions for discussion:
  • When should the hardfork take place?
  • What should the actual limit be?
  • Should the crownholder be subject to a limit, too?  It could be higher than for ordinary players, or none at all.
  • Should generals have a higher limit than other characters?  This may incentivise players to go gathering with their generals (more risk) rather than hiding them somewhere and using only hearted characters.

Bots / [ANN] AutoHunter - a Python botting framework
« on: August 06, 2014, 06:59:54 AM »
Finally, I want to announce the availability of my own botting framework in Python: AutoHunter!  You can find the code at and more information about it in the README file (see  Everything is free software under the AGPLv3, and the scripts connect to a local daemon via the RPC interface.  You don't have to compile anything, just run a Python script.

  • No need to worry about the actual RPC interface.
  • Get high-level information about the game state via an object-oriented interface.
  • The framework handles player creation (name_new and name_firstupdate) transparently for you.
  • You can focus on implementing your own strategies without having to worry about technicalities.
  • Strategies can be developed on various levels depending on your needs; you can just make use of the basic framework and write everything on your own, or you can implement abstract "behaviours" and have the framework automatically assign individual hunters to your behaviour, auto-create them on death and so on.

Also, the framework includes ready-to-use simple "example bots".  They can be used with minimal configuration and without programming knowledge, and have functionality roughly equivalent to BGB's Qt bot (basic gathering).  In addition, there are bots included to "run" after a disaster for the crown and coins on the ground.  You can use my very basic logic and extend it with your own ideas to make the bots more intelligent - and you can share your behaviours, so that others can build upon them and combine them together.

I did a "live test" during the current disaster (see also the README file), and was able to get quite some coins (240+ and there are still two hunters out gathering) with just the basic logic included in the repository and only four hunters.  One of them even briefly held the crown (so now I'm one of the crown holders in Huntercoin's history, too :D), but was killed quickly since I didn't implement any defensive strategies.  You can also see the gathering bots' behaviour live on test-net.

If you like my work here, I'll appreciate any donations to my address in the signature. ;)  Also, feel free to contact me if you have suggestions, want to share your own behaviours or whatever.  I may also be available for contract development according to your needs - let me know if you are interested in doing something advanced with the framework!

Development / Disaster & Miner Incentives
« on: April 17, 2014, 07:38:53 AM »
I've been thinking recently about how to best implement "disaster".  In particular, I want to make sure that the implementation does not create bad incentives for miners to "cheat" the system somehow.  The current plan for disaster is this:  It happens randomly with a probability that increases to 1 when the last disaster is some maximum time ago.  Which block has a disaster is based randomly on the block's hash.  (Like the other random events in the game.)

Death taxes for killed players:

One issue is whether or not to pay death taxes for the lots of killed players to the miner who finds a disaster block.

If a miner also has its own hunters on the map, it may be incentivised to dismiss a disaster block rather than publishing it to the network if no additional reward is payed.  It may be better to lose the 1 HUC block reward but save 100's of own hunters from death.

This argument may not be important, since with an increasing probability of disasters, they will happen at some point anyway.  If the probability is just large enough, another miner would produce a disaster soon, so that it doesn't pay off dismissing the block any more.

Death taxes for killed players may be a large sum (currently: 15k coins hold by players + 10k coins for the generals on the map = 25k, 4% of this is 1k death taxes).  Other miners may wish to orphan disaster blocks and try to find one themselves instead.  Even if the chances are not good, the potential reward is huge.  This may destabilise the network around disasters.  Also, I'm not sure if it is "right" to give out such large bounties for single, lucky miners.

Miners taking advantage of private chains:

Right after a disaster, huge advantages in the game can possibly be acquired within a few moves (if the crown and lots of players/coins are next to the spawn area of some base, for instance).  Miners may take the chance to keep a disaster block private and work on a few more blocks to grab the crown and those coins for themselves.  Even if a miner doesn't have 50% of the hash rate, finding 5 blocks in a row is not impossible and if it would ensure holding the crown plus thousands of coins, they will possibly take the chance.

Forced pause in the game:

I'd like to get any opinions on these and other potential issues.  Better think about everything now than have an attack later. ;)

My current idea for the second issue is to introduce a "forced pause" of 10 blocks or so after a disaster.  I. e., the 10 blocks following a disaster are special in that they give a block reward to miners, but can't include any other transactions (at least no name operations / game moves).  With this, a miner would need to find 10+ blocks in a row faster than the rest of the network in order to take advantage of a private chain.  This is much less likely, so that miners would probably instead publish disaster blocks right away to guard against them being orphaned.

It would also give everyone at least a little time to "prepare" for rushing to the coins after the disaster, not sure if that's a good or a bad thing.  These special blocks could in the future also be used to store data like the full game state and UTXO, to allow clients to skip the blockchain download prior to the last disaster entirely.  This is only a vague idea for now and not planned for the first disaster implementation, though.

As for the question about death taxes:  I'm leaning towards not paying them for disaster victims, but instead putting their coins 100% onto the map for the reason stated above (with an increasing probability, disasters will happen at some point anyway - miners could only delay them a bit if they really want to do that).  One can also think about paying the death taxes proportionally to the miners of all the "special blocks", but IMHO this again leads to incentives to try building the chain privately because the potential reward is huge compared to the risk of having the blocks orphaned.

What do you think?

Development / Test Net
« on: April 11, 2014, 06:16:29 AM »
I've set up a test-net node on my server with IP  Feel free to addnode it if you want to run test-net.  Also, I plan to mine there with a single CPU full-time.  Currently, this gets me every block, so it should hopefully make the game advance in test net.  Also, if you need coins for test net, just contact me.  (Although once you have a single one, picking up hoardes of coins on the map is trivial there. :D)

Pages: [1]