Topic: [ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain - page 66. (Read 879724 times)

I couldn't agree more, the amount coins to game/coins to miners should stay the same, and if a hardfork is eventually unavoidable, we should put some thought into it.


It's a bit risky to try asking the coin holders (perhaps this reveals them to be unaware or apathetic), but I'd like to start and ask "How fast should players be able to log out and leave the map". Even under normal circumstances (1 minute block time) having assets at risk for hours in an all out pvp killing field may (or may not) be the main reason to drive new players away.

So...Call for votes: What should be the top-level design goal?

#1 average time to logout 100 chronons, for each hunter, on average. This is about the status quo. No one can play without an advanced client and without being online for several hours.

#2 average time to logout 60 chronons. This could be achieved by increasing the number of banks.

#3 average time to logout 40 chronons.

#4 average time to logout 30 chronons. Now most hunters do have a bank to go and despawn that won't disappear before they can reach it.

#5 average time to logout 20 chronons. Could be achieved through a combination of more banks + logout if standing still for X chronons. This would keep the bank function and not dumb down the game.

#6 average time to logout 15 chronons.

#7 average time to logout 10 chronons. Below that if may become impractical, with accidental auto-logouts, or bank spam

#8 average time to logout 7 chronons.

#9 average time to logout 5 chronons. As a design goal (it's supposed to be playable on mobile)


How to vote, long version:
https://bitcointalksearch.org/topic/m.14541434

Short version
#1 send XX000.11299975 coins to yourself
#2 send XX000.21299975 coins to yourself
...
#7 send XX000.71299975 coins to yourself
#8 send XX000.81299975 coins to yourself
(XX >= 25, the more the better)
Any client or daemon can be used.

Moving these coins (or the change, if any) again will delete the vote.

Votes are counted at block 1299975. I'll post results here (betterQt makes an up-to-date result list for each block)



Yes, one-by-one, the fee structure is for next week...

The lack of SHA256 blocks being mined is definitely boosting the price because now half as many coins are going to miners with half as many blocks being mined. That means half as many coins are being sold for profit or to recoup costs.

You could interpret this to argue that we need to to update the protocol to give less newly-mined coins to miners and more to the game, but I think that would be kind of manipulative. It might also not solve the problem because it could encourage more bots in the game, who would also sell coins for profit, having a similar effect.

We don't want to make forks that affect the money supply or mining system very often, so if we're going to do it, we need to do it along with a lot of other things at the same time. That will take time and planning. Meanwhile, we have an effective block time of 2 minutes that we should fix, or gameplay suffers.

Immediate solution: we must unstuck the SHA256 mining system. I think it unlikely that someone with enough mining power to take advantage of that will be inclined to and capable of doing so; players who would know how would also know they'd be hurting the game they like to play, and devaluing their mined HUC. I think the uptrend will weaken, but not totally die, because the types of people who will take over mining will be less likely to sell their HUC than pool miners were.

Yes, as long as no sha256 blocks are produced the security hole of a low sha256 difficulty is plugged.

Perhaps the "surprise halving" also initiated the recent uptrend.


If sha256 would be replaced with some kind of Pos, I certainly would have it sit on my desktop all day. It's the only coin with a world to watch from above in its wallet

However, lowering the share of coins for the game at this point would be like ripping the soul out of Huntercoin.

Agree with keeping current setup, "human minable" should be a dogma on this coin and probably could be miners reward could be adjusted in another way like using the gamefund maybe

I already though about this in the past but never talked about, and this isn't the moment to do that, but since this is in-topic, using a refactored version of gamefund could be an alternative way to pay the miners


Just posting here for reference for future discussion:
Let me try to recap current fee mechanics and miners income (correct me if i'm wrong)

- 10 HUC are generated per block: 1 coin to miners, 8.75 coins onto the map and 0.25 coins for Crown of Fortune (as per OP post).
- Whenever a hunter goes over a bank to collect gathered coins, there is a 10% fee that goes to miners
- Whenever a hunter dies, the coins he carries are dropped on the map, minus a 4% that goes to miners
- Whenever a hunter is created, the player spend 200HUC (that are recoverable if not killed by other hunters) plus 5HUC that go, as game action fee, to GameFund
- Whenever a hunter attacks (destroy), 20 HUC are sent, as game action fee, to GameFund
- Whenever a disaster happens, every time a hunter dies by poison, the loot he carries is sent to GameFund (not stated on OP post)
- Whenever a disaster happens, if the crown holder dies by poison, the crown is dropped and the content is sent to gamefund (not stated on OP post)

there is a fee on every move too, depending even on tx size, but it's so low that can be ignored atm

From a player point of view, all these taxes are too much (mostly the attack fee) and this is something that should have been fixed already time ago but we keep being strangled by that, even because it's not balanced with coins that are on the map (if you want to cover the cost of an attack mining coins on the map it would take a lot of time even on a demi empty map).
Beside this, that it's a problem i hope will be fixed with next release of the huntercore and that anyway involve changing some PVP rules, i want to go back to Miners topic.

As a miner point of view, every block grants 1 + eventual fees applied on game transaction on that block (so the little fee on every moves, and the % decurted from death hunters and collected loot)
If we consider merged mining as a "free mining", because computed power on other coins is reused as is, without the need to waste resources for huntercoin, we could set a fixed amount that goes to miners and not based on actions on the transaction included in the block (we could give a little bonus depending on transaction count maybe, or on special blocks like the disaster one)

This way we could manage a lot better the coins and the game could really be full human mineable.


TLTR basically this is what i propose:
Every block generate 10 coins that goes all on the map (and we can even add some from gamefunds, if available, so we could decide to put 15 or 20 HUC per block)
Every current fees are considered Game Action Fees and are sent to two special container: GameFunds and MinerFunds (distribution is something to talk about, but most of the coins should go to gamefund)
Game Action Fees should be fixed (lower attack fee and no fees on dropped coins during a fight should be the primary changes)

Coins on GameFunds could be used to generate ingame contests (like reach point X,Y and stand there for 10 blocks, etc...) or to distrubute even more coins on the map per block or other funny stuff we can think about, like random NPC wandering on the map, special treasures, etc...

About miners : miners now gains a fixed amount every block, taken from MinerFunds (if available), like 0.05 HUC for every hunter on the map plus all technical tx fees (based on tx size, that actually should be 0.1 if i remind right) or anyway we can think about a dynamic formula

If we then decide to have another "non mergeable" algo, we could add a multiplier to the "miners fee formula" just for that algo


What do you think about this ideas?
What i like is that this way the game would be really be total human mine-able!!
And other PROS are we can think about having dynamic formulas for both fees and miners income and players would be happier to play because of lower fees and more income possibilities.

We really need to shake up this coin.

(I've other ideas about gameplay changes but don't want to talk about too much topics atm)

1 th/s ? Well hack i could do that with nicehash, thing is.. is there even a server running to mine too?

Icon

Alright, guys, I think we're not going to be having any problems. A friend here in Canada (where electricity is cheap and excess heat is welcome) owns a mining facility, and he says that at our current SHA256 difficulty he could solve it in approximately 1 week by dedicating 1 terahash. He will do this upon the Halvening if we set him up with our stratum, and username/password if he needs that.

The Halvening will be upon us before SnailBrain is back from Italy, so anybody who wants this to happen more immediately is welcome to reach out and help with set up.

It is true that transactions are used as inputs to the Merkle tree that composes a block, and that when a new block is mined, you start crunching new transactions and data as old ones have now already been confirmed and included in the chain.

However, this has no negative impact. Effort spent hashing from a previous block header is not wasted, as hashing does not make future hashing more likely to find the correct answer. Every time you calculate a hash, you have the same chance of calculating the correct one. The most work you could have to "throw away" would be a single hash calculation (if somebody found a block in the middle of it), but those are tiny. We make millions per second.

I like the suggestions from snailbrain.

Another option would be to add more algorithms a la myriad, where sha and scrypt are merge mineable and the other three are targeted towards GPUs and CPUs, although this increases the complexity of the system, it reduces the impact if one algo stops finding blocks.

At the other extreme is switching to a single algo like cryptonight that is supposed to be pretty equitable in terms of CPU and GPU performance, or even just scrypt - Doge et al seem to do ok just merge mining with LTC.

I'm not sure about changing distribution of mined to game coins, since the focus of the currency is the game (human mineable), I think at least 50% of rewards should go there, or just keep current setup.

For the short term, someone could rent some hashing power to try to get sha unstuck.

on vacation atm - but :

the difficulty for sha256 won't adjust until a block is mined.
it uses PPC's original smooth re targeting algo, so re-targets every block.

for sha256 we would need someone to mine one block or merge mine it - to lower the difficulty - the issue with it is that once it's lowered it's more open to abuse i think (could be unavoidable no matter what without the biggest bitcoin pool mining it).

Personally - i'd vote at changing the sha256 algo to something else anyway - something we could all have a go at mining? ... it could coincide with huntercore release which i think is good to go pretty much or wait till later.
maybe change scrypt as well (keeping dual algo though?)

1 advantage is the coin distribution could work out better? it may also give it a boost - coins that can be mined by many seem to do pretty well i believe.

we could even change the coin distrubution for the game - so maybe 80% of coins are collected from mining and 20% from in game - until there are more players? - just a random thought but i think we should be thinking about this sort of thing.

i may not get chance to respond until Monday.

correct me if I'm wrong, but i knew that (speaking simple) the block generation depends on previous generated block and the pending transactions it has to include, so you compute block hashes using transaction as inputs (and other stuff, nonce, etc..), and then look for a result that satisfy the expected result of the block generation formula (and difficult comes into play because it requires that the result is more precise, technically the number of leading zeroes in the computed hash change depending on difficulty)
I don't want to dive too much on details about nonce, merkle tree, etc.. but just trying to figure it out

Anyway the point is that afaik, in the blockchain computation formula, you have to consider the previous block hash, this mean that if a new block is generated by scrypt, your currently computing block is invalid and you must throw away your work and start recomputing using the new block header (so you must discharge the already included transaction in the other block, etc...)

this mean that if the formula is hard to compute and your chance to find it requires lot of GigaHash, it's unlikely that you'll ever find a block

Isn't this right? If yes, than we have a problem.

I don't really know the current state of ASIC miners, so I don't really know how hard it is to find a block at that difficulty.  But note that "within two minutes" is not really the correct point of view:  Mining is a Poisson process anyway, and the chances of finding a block are just the same at every moment.  It is not like recreating your block after a new scrypt block comes in somehow "invalidates" the work you did before - you just keep trying and at one point you are lucky.

oh, it's bad

looking on blockexplorer, one of the last (if not the last) sha block generated is this:
https://www.huntercoin.info/blockExplorer/block/77a1c71bf465baf598cf4cef7273d31c31e3aced84a85a26187001e313d02f2f

that's block 1289071, and its difficulty is 2260481872.0455 that sounds huge to me...so we are pretty stuck now, because it's unlikely that anyone will be able to find a so difficult block in 2 minutes (scrypt block time)

Didn't we need that f2pool at least generate a single block again now?
at the moment game is very very slow and only script blocks are generated (and less frequent than 2 minute)

Difficulty is updated per block, I think using something similar to PPC at the time (but I was not involved in the original design there).  But yes, you need to find at least one block at current difficulty, I think.

Difficulty doesn't retarget until a block or some blocks are found. Not sure what the retarget is on HUC, but since it's an older coin I'd guess it's probably closer to Bitcoin's 2000 block diff retarget than a lot of newer coins single block diff retarget. In any event, diff won't budge until someone finds a block or coin hard forks, afaik.

I'd like to know how the sha256 decay over time, because I think that soon any solo miner could try to mine

using setgenerate command on QT/daemon should start mining using the configured algo i don't remember if default algo is sha256 o scrypt


so the question is: now that there aren't sha256 blocks since days, what's current difficulty, would be possible to solomine on a PC "soon"?

You don't have to merge mine HUC or any auxpow coin, but it'd be kind of a waste not to. Typically you setup a p2pool node for the main coin, and configure it to solo mine the auxpow coin(s). I haven't actually tried mining HUC, since it has been dominated by f2pool for so long (and I don't have any ASICs anymore), but here is a guide I wrote for merge mining Unitus with parent coin Myriad. I think the steps would be generally the same: sync both daemons, setup p2pool node to mine LTC or BTC, then configure p2pool node to merge solo mine HUC.

So here is a question, how is a solo miner going to mine a merged mined coin.. ie: huc?

Icon

I think losing mining pool support was good for the price; HUC is uptrending, now. New theory: the remaining Huntercoin miners are now more likely to be Huntercoin fans who keep some or all of their HUC, instead of selling all their mining profits immediately

If you compare the difficulty and price per coin of Huntercoin vs Litecoin then all scrypt blocks currently produced are merge-mined, but they don't look like f2p blocks...

playing with a clean new Mint18, 64bit, in virtualbox. I like this one, it doesn't feel like secretly coded in java (17 did)


In the dependencies as stated in http://huntercoin.org/downloads/compile-guide/
libdb++-dev has to replace libdb5.1++-dev
so:

The install order is important (otherwise can't build from Qt Creator menu). First full update with the console (sudo apt-get update && sudo apt-get dist-upgrade)

Then Qt Creator (search "qt" in Software Manager), and then the dependencies.


git clone https://github.com/wiggi/huntercoin.git
This huntercoin-qt.pro file will also allow to load the old v1.3 release (https://github.com/chronokings/huntercoin) in Qt Creator. Perhaps it makes still sense to create wallets with it.


It was rather difficult to get it to load the blockchain (copied from a 32bit mint17.3) for the first time. iirc deleting "database" folder + starting with an empty wallet (but not with no wallet) finally made the difference between "EXCEPTION: 11DbException  Db::open: Invalid argument  huntercoin in Runaway exception" and no complaints at all -- need to test this with chain.huntercoin.org too.

A non-safemode build with some extra features for 64bit Mint18/Ubuntu 16.04 will be in the next binary release (for block 1300000).