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

[snailbrain]

Huntercore for testing is here (for a while)

http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622

for it to be released we need more people to test.

my current findings are that name_list causes crashes - at least with a pruned chain, i don't think I've tested with an unpruned chain so this could be related.
this isn't unity related as it happens in the huntercore QT console window, at least on windows.
It seems intermittent but happens a lot - i noticed first using the unity clent and huntercore debug.log the last rpc is always name_list.. further testing in the console window repeated the issue (intermittently, but enough for it to happen over a few minutes - doing game_getstate and other commands mixed in between seemed to speed up the crash)

I will check the latest release, and build for windows, along with linux and test some more.

If people could help test and report their findings then that would speed things up.

[Icon]

Thanks snail but the links you provided are for the pruned blockchain, not the actual new Qt version

Didn't know if that is what you meant to link too anyways

Icon

PS

that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c..

IMO

[OSYA]

Huntercore for testing is here (for a while)

http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622

for it to be released we need more people to test.

my current findings are that name_list causes crashes - at least with a pruned chain, i don't think I've tested with an unpruned chain so this could be related.
this isn't unity related as it happens in the huntercore QT console window, at least on windows.
It seems intermittent but happens a lot - i noticed first using the unity clent and huntercore debug.log the last rpc is always name_list.. further testing in the console window repeated the issue (intermittently, but enough for it to happen over a few minutes - doing game_getstate and other commands mixed in between seemed to speed up the crash)

I will check the latest release, and build for windows, along with linux and test some more.

If people could help test and report their findings then that would speed things up.

A link to download here can not be put?
Why does the network stop?

[wiggi]

A link to download here can not be put?

I think you'll have to build latest version from source https://github.com/domob1812/huntercore
(can be done exactly the same way as with latest Bitcoin-Qt)

[wiggi]

I was waiting to publicize Huntercore until the name_list issue was fixed, with the understanding that the beta would be pretty much over with that done. I'm hoping you guys testing it now don't find any new bugs, but we have to encourage you to look, anyways.    I'll bother snailbrain to get ITT, because I don't know how to get on Huntercore, either... managing too many cryptocurrency projects, already. Apologies!

Perhaps it's better to also wait until next update of game rules. Currently new players would just have a bad experience and they won't come back. (and tell everyone they know how much the game sucks)

3 or 2 month ago the "game doesn't allow to stop playing" was the main issue, but now there's a worse one: the 20HUC destruct fee will drive every new player into "playing at a loss" territory. Specifically, noobs will not be able to avoid combat with a group of players that has always 60...80 hunters, and it's too easy to deliberately abuse the destruct fee to make everyone else not coming back next day, so they get really all the coins.

These 2 issues need to be fixed asap, and before that, anything to promote Huntercoin, or to make playing easier with a lite client, would only backfire.

[The Bitcoin Co-op]

I was waiting to publicize Huntercore until the name_list issue was fixed, with the understanding that the beta would be pretty much over with that done. I'm hoping you guys testing it now don't find any new bugs, but we have to encourage you to look, anyways.    I'll bother snailbrain to get ITT, because I don't know how to get on Huntercore, either... managing too many cryptocurrency projects, already. Apologies!

Perhaps it's better to also wait until next update of game rules. Currently new players would just have a bad experience and they won't come back. (and tell everyone they know how much the game sucks)

3 or 2 month ago the "game doesn't allow to stop playing" was the main issue, but now there's a worse one: the 20HUC destruct fee will drive every new player into "playing at a loss" territory. Specifically, noobs will not be able to avoid combat with a group of players that has always 60...80 hunters, and it's too easy to deliberately abuse the destruct fee to make everyone else not coming back next day, so they get really all the coins.

These 2 issues need to be fixed asap, and before that, anything to promote Huntercoin, or to make playing easier with a lite client, would only backfire.

We can promote all the time if we do it to different audiences. For now I would imply that gameplay is experimental, but state that development has been proceeding and that the client is now more stable. We need people to buy HUC to sustain our community and development momentum, and speculators need to know that our dreams of an autonomous MMO are not vaporware. This can be accomplished via channels like NewsBTC... I won't be talking to any video game critics, yet

[domob]

that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c..

I wasn't aware that the crash happens with a pruned chain until recently, and am not using pruning myself - so that could indeed be a good hint.  In theory, the data for name_list is from your wallet and not the blockchain - but maybe some parts of the code (which was written before pruning existed) fails for a pruned chain.  I'll look into that, but need to sync a pruned chain first for that.

[snailbrain]

that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c..

I wasn't aware that the crash happens with a pruned chain until recently, and am not using pruning myself - so that could indeed be a good hint.  In theory, the data for name_list is from your wallet and not the blockchain - but maybe some parts of the code (which was written before pruning existed) fails for a pruned chain.  I'll look into that, but need to sync a pruned chain first for that.

looks like the issue happens with unpruned as well - it seems i may have tested both previously but just in case i have tested with a fresh unpruned chain and fresh wallet.

I sent 450 coins to the wallet, created a character and the next name_list caused a crash of the QT on windows.

Restarting the QT, the hunter seems playable..
I created an additional hunter and when it comes out of pending state, the next name_list caused a crash again.

Code:

2016-08-23 10:28:27 ThreadRPCServer method=name_pending
2016-08-23 10:28:30 ThreadRPCServer method=getblockcount
2016-08-23 10:28:30 ThreadRPCServer method=getblockcount
2016-08-23 10:28:30 ThreadRPCServer method=game_getstate
2016-08-23 10:28:30 ThreadRPCServer method=getbalance
2016-08-23 10:28:30 ThreadRPCServer method=name_list
2016-08-23 10:28:31 ThreadRPCServer method=name_pending
2016-08-23 10:28:31 ThreadRPCServer method=getblockcount
2016-08-23 10:28:31 ThreadRPCServer method=game_waitforchange
2016-08-23 10:28:45 UpdateTip: new best=2c7ef67b69e411457fdbf069ee5af854d3855850526debe861dcd655b1037eb7 height=1350630 version=0x00060101 log2_work=81.654947 tx=24468836 date='2016-08-23 10:28:27' progress=1.000000 cache=0.0MiB(66tx)
2016-08-23 10:28:46 ThreadRPCServer method=getbalance
2016-08-23 10:28:46 ThreadRPCServer method=name_list
2016-08-23 10:28:46 ThreadRPCServer method=name_pending
2016-08-23 10:28:46 ThreadRPCServer method=getblockcount
2016-08-23 10:28:46 ThreadRPCServer method=getblockcount
2016-08-23 10:28:46 ThreadRPCServer method=game_waitforchange
2016-08-23 10:29:01 ThreadRPCServer method=getblockcount
2016-08-23 10:29:05 ThreadRPCServer method=name_register
2016-08-23 10:29:05 keypool added key 109, size=101
2016-08-23 10:29:05 keypool reserve 9
2016-08-23 10:29:05 keypool added key 110, size=101
2016-08-23 10:29:05 keypool reserve 10
2016-08-23 10:29:05 CommitTransaction:
CTransaction(hash=1e8d6ead66, ver=28928, vin.size=1, vout.size=2, nLockTime=1350630)
    CTxIn(COutPoint(c61188bfc7, 1), scriptSig=47304402204af833252c966d, nSequence=4294967294)
    CTxOut(nValue=205.00000000, scriptPubKey=520574657474740b7b22636f6c6f72)
    CTxOut(nValue=39.97951000, scriptPubKey=76a914e82cfef22cecfa492ad03ee6)
2016-08-23 10:29:05 keypool keep 10
2016-08-23 10:29:05 AddToWallet 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617  new
2016-08-23 10:29:05 AddToWallet 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617  
2016-08-23 10:29:05 Relaying wtx 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617
2016-08-23 10:29:05 keypool keep 9
2016-08-23 10:29:05 ThreadRPCServer method=name_pending
2016-08-23 10:29:16 ThreadRPCServer method=getblockcount
2016-08-23 10:29:31 ThreadRPCServer method=getblockcount
2016-08-23 10:29:46 ThreadRPCServer method=getblockcount
2016-08-23 10:29:46 ThreadRPCServer method=getblockcount
2016-08-23 10:29:46 ThreadRPCServer method=game_getstate
2016-08-23 10:29:46 ThreadRPCServer method=getbalance
2016-08-23 10:29:46 ThreadRPCServer method=name_list

I notice the unity client is doing a double getblockcount which i will fix - but note that you can cause the crash by doing name_list sometimes in the console window..

[snailbrain]

sorry Icon,

i'm building the latest one now..

i've made a simple to use semi build environment where you can build for windows and for ubuntu
if you want to have a go yourself you can install vmware or virtualbox and add the ovf template. works perfect.

http://forum.huntercoin.org/index.php/topic,22255.msg26613.html#msg26613

otherwise i'll post the binaries in a bit

[snailbrain]

Here is windows - latest huntercore build

untested but no errors with building. always backup your wallet

https://mega.nz/#!4EFjnKyL!gu-TfHFtrlG23bcE9itUcx8EHQbRxYGidyIEpoaus6Q

-

note - did a quick a test - could be an issue with some coin spending RPCs unless my wallet is corrupt from the previous crashing - i will test more later.
for now, it would be good if other people could test syncing from scratch, syncing with -prune=500 and any other tests you can think of.

[domob]

Thanks for the input!  Have you (or anyone else) also experienced the crashes already on GNU/Linux?  I'm unable so far to get any crash with various combinations of name_list and other commands.  Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).

[wiggi]

I started a test: the task is to convert 50 USD worth of HUC into a fiat-pegged form aka chronoDollar, hold it for 2 weeks, then convert it back, avoiding all fees or slippage if possible.

Let's see if a Huntercoin add-on can do this better than the big inspiring example, which in this case would be Bitshares, and where the bugs and shortcomings are.
(also updated readme.md for www.github.com/wiggi/huntercoin and did my best to explain what the advanced mode is and how to get it)

I'll post and comment on every step here.


Part 1

We don't have a slick, stylisch black UI, only plain text files. (I guess it's not too difficult to have some NPCs project the order books over dark water, in-game) On the bright side, no spreads to pay between settlement prices and lowest ask.

For the test I used a new hunter ("Cortez"), and a new name address. The first 2 of the orders (they also show up in www.huntercoin.info/blockExplorer Recent Block Chat) were sent with the auction bot (the auction bot also sent the correct amount of coins), the third manually copied from adv_chrono.txt. It's a 2 step process, first gems, then chronoDollar.

Code:

Cortez CRD:GEM set bid 50 at settlement
1359987
Cortez GEM:HUC set bid 1.60 at 1980.00
1359984
Cortez GEM:HUC set bid 1.00 at 1980.00
1359975

The order to buy 50 chronoDollar "at settlement" was filled at chronon 1360001 at a rate of 0.0505 chronoDollar per gem, with the AI market maker acting as counterparty. (it's an altruistic market maker, giving buyers and sellers exactly the same quote, once per 10000 blocks)

Cortez got a "liquidity reward" because the standing sell order at 1980 was in need of buying ("old" and at settlement). Weird rule...

adventurers.txt

Code:

HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX        Cortez      2.84    -

Adventurers who own something are what would be called "delegates" elsewhere, and can do price feed (once per 10000 blocks)

Code:

 Cortez HUC:USD feed price 0.01
1359991

This was also the "median feed", and the rate of 0.0505 was calculated from this and the gem / HUC settlement of 1980.

adv_chrono.txt

Code:

 CRD:GEM trader positions (chronon 1360112, mainnet)
 ---------------------------------------------------

                                     hunter               chronoDollar   trade     trade  gems, not       long    bid    bid      ask     ask     short
storage vault key                    name          gems   position       price     P/L    at risk         risk    size   price    price   size    risk    flags

HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX   Cortez         2.94        50.00   0.0505      0.00       0.40       2.54   50.00  0.0505    0.00    0.00    0.00    bid: rollover ok

Reward for feed was paid at block 1360050. Currently, Cortez is long 50 chronoDollar (which is a futures contract) and owns 2.94 gems (an asset).
Sadly, in Huntercoin, hunters cannot own Huntercoins. This would make things so much simpler

[The Bitcoin Co-op]

I started a test: the task is to convert 50 USD worth of HUC into a fiat-pegged form aka chronoDollar, hold it for 2 weeks, then convert it back, avoiding all fees or slippage if possible.

Let's see if a Huntercoin add-on can do this better than the big inspiring example, which in this case would be Bitshares, and where the bugs and shortcomings are.
(also updated readme.md for www.github.com/wiggi/huntercoin and did my best to explain what the advanced mode is and how to get it)

I'll post and comment on every step here.


Part 1

We don't have a slick, stylisch black UI, only plain text files. (I guess it's not too difficult to have some NPCs project the order books over dark water, in-game) On the bright side, no spreads to pay between settlement prices and lowest ask.

For the test I used a new hunter ("Cortez"), and a new name address. The first 2 of the orders (they also show up in www.huntercoin.info/blockExplorer Recent Block Chat) were sent with the auction bot (the auction bot also sent the correct amount of coins), the third manually copied from adv_chrono.txt. It's a 2 step process, first gems, then chronoDollar.

Code:

Cortez CRD:GEM set bid 50 at settlement
1359987
Cortez GEM:HUC set bid 1.60 at 1980.00
1359984
Cortez GEM:HUC set bid 1.00 at 1980.00
1359975

The order to buy 50 chronoDollar "at settlement" was filled at chronon 1360001 at a rate of 0.0505 chronoDollar per gem, with the AI market maker acting as counterparty. (it's an altruistic market maker, giving buyers and sellers exactly the same quote, once per 10000 blocks)

Cortez got a "liquidity reward" because the standing sell order at 1980 was in need of buying ("old" and at settlement). Weird rule...

adventurers.txt

Code:

HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX        Cortez      2.84    -

Adventurers who own something are what would be called "delegates" elsewhere, and can do price feed (once per 10000 blocks)

Code:

 Cortez HUC:USD feed price 0.01
1359991

This was also the "median feed", and the rate of 0.0505 was calculated from this and the gem / HUC settlement of 1980.

adv_chrono.txt

Code:

 CRD:GEM trader positions (chronon 1360112, mainnet)
 ---------------------------------------------------

                                     hunter               chronoDollar   trade     trade  gems, not       long    bid    bid      ask     ask     short
storage vault key                    name          gems   position       price     P/L    at risk         risk    size   price    price   size    risk    flags

HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX   Cortez         2.94        50.00   0.0505      0.00       0.40       2.54   50.00  0.0505    0.00    0.00    0.00    bid: rollover ok

Reward for feed was paid at block 1360050. Currently, Cortez is long 50 chronoDollar (which is a futures contract) and owns 2.94 gems (an asset).
Sadly, in Huntercoin, hunters cannot own Huntercoins. This would make things so much simpler

Cool, where are you pulling the price data from? Poloniex, or something? I don't really understand how you are keeping the price pegged.

I'm actually more curious about the asset ownership dichotomy between players and their hunters. I can understand why we need a token associated with a user (or rather, his or her public/private key pair) in order to issue transactions. But I think it should be trivial to allow Hunters to hold HUC, because they already do, in a way: the coins they pick up around the map, before banking them. Conversely, I would assume that gems and chronoDollars could be made to be banked and redeemed to the player's wallet.

I think we'd basically then be looking at the banks as portals between the Huntercoin world and the real world. Assets leave it that way. Theoretically, we could also make it so Hunters can pick up assets at a bank, so then they can enter the world that way, too. Or correct me if I'm wrong...

[snailbrain]

Thanks for the input!  Have you (or anyone else) also experienced the crashes already on GNU/Linux?  I'm unable so far to get any crash with various combinations of name_list and other commands.  Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).

on ubuntu, i got a seg fault after creating 2 hunters and then the next block coming in (but i dont' see any rpc's)

restarting the daemon seems fine, until i do do a name_list.

seems same issue on ubuntu,

I think domob is travelling for the next 2 weeks or so.

If someone can fix the issue, we can provide 5k HUC bounty from the dev fund..

[wiggi]

Cool, where are you pulling the price data from? Poloniex, or something? I don't really understand how you are keeping the price pegged.

The principle is similar to Bitshares really, including the 3:1 initial margin requirement for shorts. (*)

Main difference is probably, pegged asset and collateral is not conflated into one thing (bitUSD) but longs own both (like ES futures, you buy stock futures and keep the dollars, they only get "frozen")

Then, price data is only needed (and rewarded) every 10k blocks, so that feed can be done manually by players without cost or special expertise.
This also means settlement (getting in or out at a fixed price) is only possible every 10k blocks.

And I included a "free insurance" against drop of gem price while getting out (would not be needed if the in-game markets had lots of liquidity) The entire system is too complex to describe in a single post, just watch it in motion, it's fascinating

(*) the short in this case is a NPC (one with no visual representation in-game yet)

Code:

 CRD:GEM trader positions (chronon 1363027, mainnet)
 ---------------------------------------------------

                                     hunter               chronoDollar   trade     trade  gems, not       long    bid    bid      ask     ask     short
storage vault key                    name          gems   position       price     P/L    at risk         risk    size   price    price   size    risk    flags

npc.marketmaker.zeSoKxK3rp3dX3it1Y   Sox'xiti    490.293      -210.00   0.0505    -1.296    458.187       0.00  205.00  0.0494  0.0515   94.00   30.60    bid: ok ask: ok

If you think about it, this could be the first AI in history who (and not just it's human masters) owns something, assuming code changes to steal his stuff are generally unacceptable, and Ether didn't have a bunch of these guys earlier.

I'm actually more curious about the asset ownership dichotomy between players and their hunters. I can understand why we need a token associated with a user (or rather, his or her public/private key pair) in order to issue transactions. But I think it should be trivial to allow Hunters to hold HUC, because they already do, in a way: the coins they pick up around the map, before banking them.

If a player (and their hunter) can enter contracts involving "loot" (i.e. the coins they pick up around the map, before banking them) it must not be allowed to just walk the hunters to bank and take it away. And impossible for the hunter to die and lose the loot.

This would require a hardfork that must also specify exactly what can be done with the loot.

Conversely, I would assume that gems and chronoDollars could be made to be banked and redeemed to the player's wallet.

In a way, currently they instantly autobank. It's the privkeys in the player's wallet that decide who can do stuff, like sending to other addresses, or trade.

I think we'd basically then be looking at the banks as portals between the Huntercoin world and the real world. Assets leave it that way. Theoretically, we could also make it so Hunters can pick up assets at a bank, so then they can enter the world that way, too. Or correct me if I'm wrong...

Theoretically, I would do the "bring coins already banked back into the game as loot" thing in the way that you can send coins to a coin-eater address that is associated with a hunter's name address, and the coins get re-issued to that hunter as "loot2_deathtax_already_paid". Naturally, this hunter wouldn't want to walk around on the battlefield.

[merlin0113]

Thanks for the input!  Have you (or anyone else) also experienced the crashes already on GNU/Linux?  I'm unable so far to get any crash with various combinations of name_list and other commands.  Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).

on ubuntu, i got a seg fault after creating 2 hunters and then the next block coming in (but i dont' see any rpc's)

restarting the daemon seems fine, until i do do a name_list.

seems same issue on ubuntu,

I think domob is travelling for the next 2 weeks or so.

If someone can fix the issue, we can provide 5k HUC bounty from the dev fund..

https://bitcointalk.org/index.php?topic=1377121.0
just for your information

[wiggi]

I won't be talking to any video game critics, yet

The antithesis to Huntercoin's gameplay is perhaps a game that does require (and allow) player input only at time of character creation.
This would be a programmable alife predator-prey simulation.

Once the (totally stupid, hence almost no memory or cpu footprint) critters are sent into battle, players can only watch. (but don't have to, in case of players with jobs)

It could run alongside Huntercoin, no player input also means almost no UI programming (not my thing)
A challenge is to make it so that no "hunter" is necessary to play (i.e. to communicate with the Huntercoin blockchain without a hunter)

[crackfoo]

Guys,

when I try to start stratum with huntercoind I get this error:

2014-02-03 10:26:09,764 ERROR mining # CoinD does not support getblocktemplate!!! (time to upgrade.)

Can you support getblocktemplate, or is something else wrong?

namecoin/huntercoin does not have getblocktemplate

but, maybe there is some trick or patch - possibly some big btc pools have some idea - (with merged mining btc + nmc)

for now will have to wait - maybe will add in the future

There is... NMC I just installed has getblocktemplate... maybe you can check it out and update HUC?

https://github.com/UNOMP/namecoin-core

been 2 years now after all

[jwinterm]

I won't be talking to any video game critics, yet

The antithesis to Huntercoin's gameplay is perhaps a game that does require (and allow) player input only at time of character creation.
This would be a programmable alife predator-prey simulation.

Once the (totally stupid, hence almost no memory or cpu footprint) critters are sent into battle, players can only watch. (but don't have to, in case of players with jobs)

It could run alongside Huntercoin, no player input also means almost no UI programming (not my thing)
A challenge is to make it so that no "hunter" is necessary to play (i.e. to communicate with the Huntercoin blockchain without a hunter)

This is a very interesting idea. Kind of like a game of life coin or something. Is it possible this could be implemented alongside HUC, or does it make more sense to launch a separate chain?

[domob]

Guys,

when I try to start stratum with huntercoind I get this error:

2014-02-03 10:26:09,764 ERROR mining # CoinD does not support getblocktemplate!!! (time to upgrade.)

Can you support getblocktemplate, or is something else wrong?

namecoin/huntercoin does not have getblocktemplate

but, maybe there is some trick or patch - possibly some big btc pools have some idea - (with merged mining btc + nmc)

for now will have to wait - maybe will add in the future

There is... NMC I just installed has getblocktemplate... maybe you can check it out and update HUC?

https://github.com/UNOMP/namecoin-core

been 2 years now after all

Not sure what you are talking about - Namecoin Core (whose official repository is not the one you linked) has getblocktemplate disabled, although we are thinking about re-enabling it.  We also already have an updated version of HUC, called Huntercoin Core.  Check out my posts a bit up in the thread about that.