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

[MithrilMan]

well one of the reason as stated above is in the old version we had to walk a mile ~ hour+ to get to the coins less combat, but now we are so close together, combat comes into play more often, so its now more noticeable

I always monitored/played the game since the begin and i never faced so high burst of blocks, except when f2pool halted a bit his power and then restarted

also not having a giant like f2pool to mine 99% of our blocks just adds even more randomness to the mix.

I think this is the main issue, or better there is low mining power and sometimes someone turn on for a bit his horses and BUM...

[1715393710]

1715393710

[1715393710]

1715393710

[1715393710]

1715393710

[1715393710]

1715393710

[jwinterm]

well one of the reason as stated above is in the old version we had to walk a mile ~ hour+ to get to the coins less combat, but now we are so close together, combat comes into play more often, so its now more noticeable

I always monitored/played the game since the begin and i never faced so high burst of blocks, except when f2pool halted a bit his power and then restarted

also not having a giant like f2pool to mine 99% of our blocks just adds even more randomness to the mix.

I think this is the main issue, or better there is low mining power and sometimes someone turn on for a bit his horses and BUM...

Two options come to mind for me:

• Use a more responsive diff retargeting algorithm
• Add more algorithms (like Myriadcoin uses five hashing algorithms, each with a five minute target, so averages out to one minute blocks; myriad also disallows a single algo from finding more than two or three blocks in a row I think)

Or convince f2pool to come back and mine both algos again.

[The Bitcoin Co-op]

Yeah, SnailBrain has wanted to change the mining system for a long time. A lot of these issues will be ameliorated when we have more and more stable/continuous hash power.

[snailbrain]

well one of the reason as stated above is in the old version we had to walk a mile ~ hour+ to get to the coins less combat, but now we are so close together, combat comes into play more often, so its now more noticeable

I always monitored/played the game since the begin and i never faced so high burst of blocks, except when f2pool halted a bit his power and then restarted

also not having a giant like f2pool to mine 99% of our blocks just adds even more randomness to the mix.

I think this is the main issue, or better there is low mining power and sometimes someone turn on for a bit his horses and BUM...

Two options come to mind for me:

• Use a more responsive diff retargeting algorithm
• Add more algorithms [/b](like Myriadcoin uses five hashing algorithms, each with a five minute target, so averages out to one minute blocks; myriad also disallows a single algo from finding more than two or three blocks in a row I think)

Or convince f2pool to come back and mine both algos again.

basically this

probably like the kimoto gravity well or whatever it was called which was implemented by someone.

The reason for adding the dual algo was to limit purposeful fluctuations, but without many big pools on both algos, it won't work great.. i did write a doc a few weeks ago about using more algos (myriad coin based, which was probably a bit of a copy of huc dual algo to begin with maybe ..),

If there are many algos, it's still possible for someone with big hash to blast one every now and then - but i did not know that myriad does not let you mine 2-3 blocks in a row of 1 algo - that could be interesting and worth thinking about.

-

miners are (most probably) merge mining, miners pool hop, new pools are merge mining, peoples pools/daemons crash, multipools,

It's unlikely someone is speeding up and slowing down on purpose, why would they, they are probably best just mining the parent chain as much as they can based on HUCs current value..

-

with huntercoin, sometimes you can get some big oscillations between between the algos if they get a lot of hash then get dropped...


difficulty has increased over the last few days for sha256.. overall, blocks should be faster than normal if difficulty is increasing until it balances out back to 2min (not checked script though)

block 1562000
Time: 2017-01-15 04:44:28
Difficulty: 10573387

block 1563000
Time: 2017-01-16 03:04:05
Difficulty: 7108925

block 1564000
Time: 2017-01-17 01:54:26
Difficulty: 4901020

block 1565000
Time: 2017-01-17 20:59:06
Difficulty: 4551718

block 1566000
Time: 2017-01-18 07:11:02
Difficulty: 7070979

block 1567000
Time: 2017-01-18 19:45:03
Difficulty: 9216295

block 1568000
Time: 2017-01-19 09:58:56
Difficulty: 10694642

block 1569000
Time: 2017-01-20 00:49:06
Difficulty: 11565838

block 1570000
Time: 2017-01-20 16:39:53
Difficulty: 11742223

Block 1571000
Time: 2017-01-21 07:22:35
Difficulty: 12924133

Block 1571200
Time: 2017-01-21 10:34:59
Difficulty: 13027035

-

Part of my job is as a data analyst, and although there isn't much to analyse here, I'm well versed in tableau and dashboard creation.

If someone is able to output every block/info to mysql (in realtime too) and configure on my VPS - probably similar to what BGB has done, i will create all the dashboards possible, and upload to tableau public so people can see all the stats in real time - I can also combine this data with crypto-exchange data (tableau's webconnector works with most exchanges with an api that i have tried).

I've been meaning to get someone to do this for a while, just not had the chance.

[MithrilMan]

If someone is able to output every block/info to mysql (in realtime too) and configure on my VPS - probably similar to what BGB has done, i will create all the dashboards possible, and upload to tableau public so people can see all the stats in real time - I can also combine this data with crypto-exchange data (tableau's webconnector works with most exchanges with an api that i have tried).

what information did you need to be dumped?
what's your VPS configuration?

I can build something in .Net Core (works on linux) if this can help the community
just something as simple as an RCP wrapper around huntercore, to get some data and save it on mysql or wherever, of course it would need a reachable huntercore on your VPS or another location

[wiggi]

And look at the screenshot i've just taken, there are 5 or 6 blocks generated per minute.... this isn't a luck matter, this is an hashpower matter or something else

It could be a pool switching from mining BTC + some merge-minable coins to mining other non-merge-minable coins based on realtime exchange rates, but not sure how realistic such a scenario is.

[snailbrain]

If someone is able to output every block/info to mysql (in realtime too) and configure on my VPS - probably similar to what BGB has done, i will create all the dashboards possible, and upload to tableau public so people can see all the stats in real time - I can also combine this data with crypto-exchange data (tableau's webconnector works with most exchanges with an api that i have tried).

what information did you need to be dumped?
what's your VPS configuration?

I can build something in .Net Core (works on linux) if this can help the community
just something as simple as an RCP wrapper around huntercore, to get some data and save it on mysql or wherever, of course it would need a reachable huntercore on your VPS or another location

that would be useful, probably for other cryptos as well.

there is some posts etc about doing it with bitcoin, but i've not researched it properly..

to start i'd just install ubuntu 16.04 server on a VM, install current mysql server, huntercore etc..
not sure what you will need - i can give ssh access or tell me what you want installing.. is it just an exe and i use mono to run it?

will it also update the mysql table(s) realtime when i a new block comes in?

-

for data -
probably 1 table with all the variable info for each block (if you can process gamestate as well, that would be a bonus)..
probably fields such as > blockhieght, algo (0 or 1), difficulty, unix time, median time, size, weight(i should google this i guess), and anything else you can think of
If you can do gamestate stuff as well > Total generals and total hunters, and anything else if it is easy for each block.. (can do that later if that's more of a pain)

only need the raw values (no need to calculate unix time, or put the difficulty type etc).

all that can go in one table..

Could also output getchaintips into another table, although it would be more of a live table with no historical data for ach block .. not sure how i would visualize it but could use to see if there is any forking going on.

let me know what you need me to do..

(would of course need to parse all the blocks from block 1 till now too)

[wiggi]

Well if anyone of you actually mined instead of just playing this game, you would all realize mining is a random luck draw, sometimes you find a block in (using btc) 10 mins sometimes longer and sometimes even under 10 mins. Making a turn base game on something that is so random is like playing on a ice lake, one day your going to fall through.

Perhaps there's a way to reduce the randomness by reducing the blocktime and make 1 game turn every X blocks (e.g. block time 20 seconds, 1 game turn every 3 blocks)

In a RPG, 3d20 damage is also more uniform than 1d60...

Not to mentioning some blocks get orphaned (like it never happened). Granted its a great idea that humans are the miners instead of ASIC but playing a game of turn base on a engine that is random in nature is not the best idea..

IMO

Icon

If a sha256 block comes shortly after a scrypt block, then the scrypt block is likely to get orphaned, because in Huntercoin, both add to the total chain work according to a constant ratio sha256 diff/scrypt diff, and in practice this is in favor of the sha256 block

[MithrilMan]

to start i'd just install ubuntu 16.04 server on a VM, install current mysql server, huntercore etc..
not sure what you will need - i can give ssh access or tell me what you want installing.. is it just an exe and i use mono to run it?

will it also update the mysql table(s) realtime when i a new block comes in?

I recently rent 2 micro VM to start hack around with linux and VM and I've your same configuration (ubuntu 16.04 server) but i don't have space/ram to host huntercore or mysql anyway i should be able to work on your VM, i already installed on mine the dotnet core needed (it's just a matter to update apt with a new repository url and then apt-get the needed dotnet-core stuff to be able to compile and run .Net Core app

Anyway i can start implementing and testing on my system, maybe you can create mysql db and tables you'd like to be populated, and let my VM run the daemon that get info from your server (getblockinfo, etc...) and write back on your mysql, so once it's ready it's just a matter to deploy it on your server and i don't need access to your machine
I can give you the IP of my VM so you can allow my machine to connect to your huntercore RPC service

-

for data -
probably 1 table with all the variable info for each block (if you can process gamestate as well, that would be a bonus)..
probably fields such as > blockhieght, algo (0 or 1), difficulty, unix time, median time, size, weight(i should google this i guess), and anything else you can think of
If you can do gamestate stuff as well > Total generals and total hunters, and anything else if it is easy for each block..

only need the raw values (no need to calculate unix time, or put the difficulty type etc).

all that can go in one table..

Could also output getchaintips into another table, although it would be more of a live table with no historical data for ach block .. not sure how i would visualize it but could use to see if there is any forking going on.

Ok I'd say you could:
- configure your VM with huntercore
- install MySQL and create the database with tables you'd like to have populated
- open RPC service to my IP
- give me the connection string to reach your MySql db
- (bonus) install dotnetcore on your server, pretty straightforward ( https://www.microsoft.com/net/core#linuxubuntu )


once that's ready, wait some time that i find the time to do the app and test it and then I'll give you the app or i'll install it on your vm

(would of course need to parse all the blocks from block 1 till now too)

ok so we are talking about 2 components: a realtime one that runs as a daemon that polls the RPC, and an historical one to fill the gaps
note that gathering blocks information is quite fast even on historical data and seems to work even on a pruned node (i need just the header info)

getblockhash 1
> a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786

getblockheader a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786
> {
  "hash": "a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786",
  "confirmations": 1571465,
  "height": 1,
  "version": 131585,
  "versionHex": "00020201",
  "algo": 1,
  "merkleroot": "09b1b907a0b33312822acb00bc3d7441fa4ee4842d6cf16ef090dc48e2eb70c6",
  "time": 1391264537,
  "mediantime": 1391264537,
  "nonce": 57104,
  "bits": "1e0fffff",
  "difficulty": 0.0002441371325370145,
  "chainwork": "0000000000000000000000000000000000000000000000000000000200011001",
  "previousblockhash": "00000000db7eb7a9e1a06cf995363dcdc4c28e8ae04827a961942657db9a1631",
  "nextblockhash": "000000000e14e03fa502dad4b69184c23690bd16455bf0dc7e5ea76ed033c961"
}


and so if that info is enough would be quite fast to populate the historical data, but gamestate is a loooooot slower

[snailbrain]

using just the headers would be a start. we can use that to kick it off to see if we can get it working. With just the header info we can only look at both algos blocktimes/difficulty.

would be good to get more info to play with like block size, and some simple gamestate data (how many on the map), combine that with exchange data etc etc.

once it's parsed all the previous blocks - performance for adding each block should be ok.. but it would need to consider reorgs for real-time..
tbh, Tableau doesn't work too well in real time and the Tableau public version may have some limits for syncing with DB - e.g. may be every 10mins or something.

So real-time doesn't need to be real-time - it could just update the db with new info every few minutes if that is easier. or, once a day - i can set a cronjob if just need to execute your program every now and then.

-
we could just use a blockexplorer like ABE and modify it, but i'd need help. From my side, all i need is a db to connect to.

-

to give DB access i will need an IP from you to allow through the firewall (can send in pm or on skype).

I'll setup tomorrow if i get time, on a vm with lots of diskspace..

[The Bitcoin Co-op]

Well if anyone of you actually mined instead of just playing this game, you would all realize mining is a random luck draw, sometimes you find a block in (using btc) 10 mins sometimes longer and sometimes even under 10 mins. Making a turn base game on something that is so random is like playing on a ice lake, one day your going to fall through.

Perhaps there's a way to reduce the randomness by reducing the blocktime and make 1 game turn every X blocks (e.g. block time 20 seconds, 1 game turn every 3 blocks)

In a RPG, 3d20 damage is also more uniform than 1d60...

There are other ways to fix it, too. For example, if some players issue transactions in one block, and some confirm in the next block but not all of them, the gamestate could choose not to update until all of the transactions are confirmed, giving each player an equal chance.

It could be done map-wide like that, affecting the base speed of the game. Or it could be done only for players in close proximity such that combat might occur, causing a bit of a time warping effect.

Overall, I don't see it as a huge problem to fix, and I think it will be, soon. Everyone just has to be patient

[domob]

There are other ways to fix it, too. For example, if some players issue transactions in one block, and some confirm in the next block but not all of them, the gamestate could choose not to update until all of the transactions are confirmed, giving each player an equal chance.

This is unfortunately not very straight-forward to do.  There's no network consensus about unconfirmed transactions (that's precisely why they are still unconfirmed), so one cannot take them into account for consensus-stuff like game-state transitions.  (There might be more complex hacks around this in some way, but I doubt one can find a good solution that fully retains Huntercoin's trustlessness and decentralisation.)

[The Bitcoin Co-op]

There are other ways to fix it, too. For example, if some players issue transactions in one block, and some confirm in the next block but not all of them, the gamestate could choose not to update until all of the transactions are confirmed, giving each player an equal chance.

This is unfortunately not very straight-forward to do.  There's no network consensus about unconfirmed transactions (that's precisely why they are still unconfirmed), so one cannot take them into account for consensus-stuff like game-state transitions.  (There might be more complex hacks around this in some way, but I doubt one can find a good solution that fully retains Huntercoin's trustlessness and decentralisation.)

What if you made blocks really fast, and then made the gamestate wait for at least 2 confirmations instead of 1? Could it then take the 1-confirmed transactions into account and hold off including others that were issued in the same block but already got to 2 confirmations?

[Daffadile]

I like the installer it is cute when it tells you to go to polo to buy HUC while waiting for the installer.
Also I was expecting the blockchain to take much longer but I am only 5 weeks behind so that is cool. Hopefully I will be playing soon.

[snailbrain]

@ MithrilMan

mysql all setup for you - tested and working.

I think this could be very interesting if we can fill it with as much data as possible.. and fun.
If it doesn't work too great, we can have a look at giving someone a bounty to modify ABE for us -- or just make some script that parses the json and imports to mysql

[Daffadile]

I started playing and I have no idea what I am doing I only just figured out I can't collect the clear coins till they have gone solid. I think that means they under respawn ? I saw a red star and walked on to it then made coffee and came back and I disappeared. I assumed I died. Why ? Did the star kill me ? Also how do I sed my coins back to my wallet ? It says I must find a bank that respawns but where ? What do they look like ?

A short guide from anyone would be much appreciated.

[The Bitcoin Co-op]

I started playing and I have no idea what I am doing I only just figured out I can't collect the clear coins till they have gone solid. I think that means they under respawn ? I saw a red star and walked on to it then made coffee and came back and I disappeared. I assumed I died. Why ? Did the star kill me ? Also how do I sed my coins back to my wallet ? It says I must find a bank that respawns but where ? What do they look like ?

A short guide from anyone would be much appreciated.

The red stars are banks. The coins used to make your Hunter and any coins he/she was carrying are returned to your wallet when you go over it.

[domob]

There are other ways to fix it, too. For example, if some players issue transactions in one block, and some confirm in the next block but not all of them, the gamestate could choose not to update until all of the transactions are confirmed, giving each player an equal chance.

This is unfortunately not very straight-forward to do.  There's no network consensus about unconfirmed transactions (that's precisely why they are still unconfirmed), so one cannot take them into account for consensus-stuff like game-state transitions.  (There might be more complex hacks around this in some way, but I doubt one can find a good solution that fully retains Huntercoin's trustlessness and decentralisation.)

What if you made blocks really fast, and then made the gamestate wait for at least 2 confirmations instead of 1? Could it then take the 1-confirmed transactions into account and hold off including others that were issued in the same block but already got to 2 confirmations?

Yes, that might be a possible approach.  But I'm not sure what that would buy you - then you still have to get a miner to include your tx, and tx sent at the "same time" might still not confirm in the same block.  Also making blocks very fast is problematic due to orphan blocks.

[Gash]

I like the installer it is cute when it tells you to go to polo to buy HUC while waiting for the installer.
Also I was expecting the blockchain to take much longer but I am only 5 weeks behind so that is cool. Hopefully I will be playing soon.

Installer is acting up. I tried to reverse engineer it and found odd pieces of code that looked like malware. I will look at it closer and post my findings in this thread but bear in mind I cant sit here all day long helping u with fixing and peer reviewing that weird code.

[snailbrain]

I like the installer it is cute when it tells you to go to polo to buy HUC while waiting for the installer.
Also I was expecting the blockchain to take much longer but I am only 5 weeks behind so that is cool. Hopefully I will be playing soon.

Installer is acting up. I tried to reverse engineer it and found odd pieces of code that looked like malware. I will look at it closer and post my findings in this thread but bear in mind I cant sit here all day long helping u with fixing and peer reviewing that weird code.

There is no malware. Check with virus total.