domob1812 / huntercore

Reimplementation of Huntercoin on the current Bitcoin Core / Namecoin Core code.

Huntercore

http://huntercoin.org/

What is Huntercoin?

Huntercoin is a decentralized open source blockchain-based MMORPG game, fork of the cryptocurrency Namecoin. This program works only as wallet, it does NOT cointain game's tab.

License

Huntercore is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Binaries

To get binaries, blockchain and game's UI (Unity), visit the official thread on Bitcointalk.

huntercore's Issues

Easier triggering of game-logic forks from regtests

Currently, game-logic hard forks trigger on regtest mode similarly to how they trigger ordinarily: After mining a sufficient number of blocks. These numbers also can't be too small even on regtest, since otherwise we lose the ability to run tests at pre-fork logic beyond a small number of moves (and tests might very well need to run for many moves, if hunters need to collect coins and so on).

Nevertheless, especially for implementing upcoming game-logic forks, it would be very good to be able to trigger forks "at will" in regtests so that we can properly implement tests for the post-fork logic and also the fork itself.

For this, I propose to add a new RPC command setforkheight that will only be available in regtest mode. This command can be used to change the "block height" the daemon thinks it is at for fork-determination purposes only (without actually changing the height). That can be implemented relatively easily, by simply keeping a "height delta" variable in the chain params and using it to offset the actual height when checking for a fork. With this, we can keep large fork heights on regtest mode (e. g., the ones from testnet) and still trigger any fork at will easily. (This command would even allow to "untrigger" a fork, but that's presumably something not very useful for actual tests as it could never occur in practice.)

[question] Creating a transaction "by hand"

not sure where/how to post this question, this is not an issue, more a technical question about what should I do in order to create a transaction outside of huntercore, (e.g. using listunspent) so that i could be able to chose by myself the change address, etc...

I think this could even be useful to create a centralized wallet to serve multiple players so that a player can chose to not install a node and run on a 3rd party (trusted) node/service (the milestone for having a web/smartphone game client)

What i would like to try as a first step, is reserving a single address like if it's rappresenting a player account, and so creating transactions using only unspent coins that belongs to that address

So 1st thing should be call listunspent passing the address to filter unspents coins (side note: i can't find the right syntax to use in console windows inside the qt wallet to specify the address array, it's a bug?)

then i need to create the raw transaction using createrawtransaction right? (tips?)

then i need to signrawtransaction?

and finally sendrawtransaction?

i suppose i've to create my name_update data like stated in createrawtransaction console help, did i miss some steps?
did you have some example about how to correctly format/check the transaction?
how did i add fees to that? If i've understood well, any input that doesn't goes to output is a fee for miners, but how is the game move fee that goes to gamefund handled???

thanks

Can't compile macOS High Sierra: error: call to 'Pair' is ambiguous

Get the following error when compiling on macOS High Sierra:
rpc/misc.cpp:682:27: error: call to 'Pair' is ambiguous
transactions.push_back (Pair ("game", vGameTx.size ()));

Can't compile macOS High Sierra: error: call to 'Pair' is ambiguous

Describe the issue

Get the following error when compiling on macOS High Sierra:
rpc/misc.cpp:682:27: error: call to 'Pair' is ambiguous
transactions.push_back (Pair ("game", vGameTx.size ()));

regression (OP_RETURN missing in sendtoaddress)

huntercore doesn't have the extended sendtoaddress accepting a tag string (that uses OP_RETURN)

no peers

build does not connect by default to any peers, also it says

"errors": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"

When will the release be ?

No peers | 0 connections

Hi, Can you please post here config with addnode ? I get 0 connections

Conflicted transactions (reopen)

In my wallet "often" i find some "Conflicted" transaction, and most of this happen when i'm fighting (destructing or moving around enemies, coincidence?), looking for info, I checked which tx were conflicting and i found they were some tx that were confirmed few blocks ahead (2 or 3), what's happening there?

Of course this often lead to lose the hunter (so 100 huc) because he missed the action I required (destruct) while the enemy didn't... this is a big problem of course, but what's the cause? there is a bug in the wallet that reuse some coins? Sometimes i receive even errors during my name updates, stating that i'm double spending coins (not sure this relate then to those conflicting transaction because the error seems to pop up less frequently)

I just created some random hunters to test if i can replicate the issue, and i found one, this is my findings (lot of data!):

---

Conflicted tx:

---

Status: conflicted with a transaction with 3 confirmations, broadcast through 3 node(s)
Date: 11/01/2017 23:10
Total debit: 101.00000000 HUC
Total credit: -101.00000000 HUC
Net amount: -0.01000000 HUC
Transaction ID: a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61
Transaction total size: 403 bytes
Output index: 0

---

Using ListTransaction i extracted those info about the conflicted tx and the 2 confirmed that caused conflict

---

{
"account": "",
"address": "H9s3Wkfjfd6FBB8EKzH79LeNK7LUcbeAXm",
"name": "update: labi",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -0.01000000,
"confirmations": -8,
"trusted": false,
"txid": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"walletconflicts": [
"55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4"
],
"time": 1484172639,
"timereceived": 1484172639,
"bip125-replaceable": "unknown",
"abandoned": false
}

{
"account": "",
"name": "killed: labi",
"category": "killed",
"amount": 0.00000000,
"vout": 1,
"fee": 0.00000000,
"confirmations": 8,
"blockhash": "e696ce60f7e6145f0f2f91a1a8d5d78ae8b26826cecdb26736704c44d8a5efac",
"blockindex": 17,
"blocktime": 1484172636,
"txid": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"walletconflicts": [
"a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61"
],
"time": 1484172639,
"timereceived": 1484172688,
"bip125-replaceable": "no",
"abandoned": false
},

{
"account": "",
"address": "HQmVHLGD3AKYbiV3Nu3cE5aRPQyAtMKnqK",
"name": "update: Cep",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -1.01000000,
"confirmations": 6,
"blockhash": "b216b05586592f383933dd5762e105b314d9c50379d19f73a4ac2844a8951e33",
"blockindex": 1,
"blocktime": 1484172720,
"txid": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"walletconflicts": [
"a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61"
],
"time": 1484172711,
"timereceived": 1484172711,
"bip125-replaceable": "no",
"abandoned": false
}

---

Conflicted Transaction Detail

---

{
"txid": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"hash": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"size": 403,
"vsize": 403,
"version": 28928,
"locktime": 1557211,
"vin": [
{
"txid": "1fbe5c4bd6db40690b18c2ceb2c2b66800d290bb9e432bb920e5970862943c4a",
"vout": 0,
"scriptSig": {
"asm": "3045022100fb85c66d1fe9901d127321b03a995836bf96c839f66dbd3e2338184962da60e6022066f3c820339844c545c4fa6624ce272b0b5a25ce50d4094b6405d26636cc5f10[ALL] 023770a1b31bf5d3924daa22342b7cb3dd7e80c4d3c9cfa02fa51497b2f816af26",
"hex": "483045022100fb85c66d1fe9901d127321b03a995836bf96c839f66dbd3e2338184962da60e6022066f3c820339844c545c4fa6624ce272b0b5a25ce50d4094b6405d26636cc5f100121023770a1b31bf5d3924daa22342b7cb3dd7e80c4d3c9cfa02fa51497b2f816af26"
},
"sequence": 4294967294
},
{
"txid": "f81c18f99e5c5b0a6e332f5d371ee7d5e5a5cfd3c28506281382fefcf85d6186",
"vout": 2,
"scriptSig": {
"asm": "304402206cd673c4fd5d3a22fb2601eb6d28d486ffb8493b2334b2205e603c89cd66da85022063b9d89926657fdc021a8e0bdc48b3d8416acea81a2a12c3a2a2447cd8279a0a[ALL] 02db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc",
"hex": "47304402206cd673c4fd5d3a22fb2601eb6d28d486ffb8493b2334b2205e603c89cd66da85022063b9d89926657fdc021a8e0bdc48b3d8416acea81a2a12c3a2a2447cd8279a0a012102db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 101.00000000,
"n": 0,
"scriptPubKey": {
"nameOp": {
"op": "name_update",
"name": "labi",
"value": "{"0":{"wp":[97,487]}}"
},
"asm": "OP_NAME_UPDATE 1768055148 7b2230223a7b227770223a5b39372c3438375d7d7d OP_2DROP OP_DROP OP_DUP OP_HASH160 24aca122ba5885b2bc29521c64138259e21be99d OP_EQUALVERIFY OP_CHECKSIG",
"hex": "53046c616269157b2230223a7b227770223a5b39372c3438375d7d7d6d7576a91424aca122ba5885b2bc29521c64138259e21be99d88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"H9s3Wkfjfd6FBB8EKzH79LeNK7LUcbeAXm"
]
}
},
{
"value": 1.79000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 a85870cc40c108332e28ecea5307dc72b79e5ecd OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914a85870cc40c108332e28ecea5307dc72b79e5ecd88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HMsFrXuGy9gCogXZtP86gPiauFxARZwMKn"
]
}
}
]

---

**Decoded first confirmed transaction that caused conflict
249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4

---

{
"txid": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"hash": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"size": 476,
"vsize": 476,
"version": 28928,
"locktime": 1557212,
"vin": [
{
"txid": "cf185b52b2e8dbbcd15e4af26d9272b515f4018fb7b94279c348b975b7363dfc",
"vout": 1,
"scriptSig": {
"asm": "3044022076f34907e4d2327e1bd904b6c71c46cbf813833ae6fbbd081baaad880deabf8f022026970415b26cd781a7d011bc75549e514f6f2ed7741c89e8eb6ceef6a534ee3a[ALL] 0301e6b8737c494655f357d0bb20a9197f1d655fd8d5227790c73def1bb57eeac5",
"hex": "473044022076f34907e4d2327e1bd904b6c71c46cbf813833ae6fbbd081baaad880deabf8f022026970415b26cd781a7d011bc75549e514f6f2ed7741c89e8eb6ceef6a534ee3a01210301e6b8737c494655f357d0bb20a9197f1d655fd8d5227790c73def1bb57eeac5"
},
"sequence": 4294967294
},
{
"txid": "f81c18f99e5c5b0a6e332f5d371ee7d5e5a5cfd3c28506281382fefcf85d6186",
"vout": 2,
"scriptSig": {
"asm": "3045022100df720d669b8029d1f0cc18ba1904c28b0fad315959bb92617f28314d91ff14bf0220243ff2dc217ed9c5a8f736e523e378ac6ded64e442a8ca58039b7dfc4f5ccbe0[ALL] 02db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc",
"hex": "483045022100df720d669b8029d1f0cc18ba1904c28b0fad315959bb92617f28314d91ff14bf0220243ff2dc217ed9c5a8f736e523e378ac6ded64e442a8ca58039b7dfc4f5ccbe0012102db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 102.00000000,
"n": 0,
"scriptPubKey": {
"nameOp": {
"op": "name_update",
"name": "Cep",
"value": "{"0":{"wp":[429,187,429,188,431,190,431,192,430,191,430,194,431,194,432,193],"destruct":true}}"
},
"asm": "OP_NAME_UPDATE 7365955 7b2230223a7b227770223a5b3432392c3138372c3432392c3138382c3433312c3139302c3433312c3139322c3433302c3139312c3433302c3139342c3433312c3139342c3433322c3139335d2c226465737472756374223a747275657d7d OP_2DROP OP_DROP OP_DUP OP_HASH160 c82987edc8a616c86aec7720a743efc970599286 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "53034365704c5e7b2230223a7b227770223a5b3432392c3138372c3432392c3138382c3433312c3139302c3433312c3139322c3433302c3139312c3433302c3139342c3433312c3139342c3433322c3139335d2c226465737472756374223a747275657d7d6d7576a914c82987edc8a616c86aec7720a743efc97059928688ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HQmVHLGD3AKYbiV3Nu3cE5aRPQyAtMKnqK"
]
}
},
{
"value": 0.79000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 3e68df06302ee9a19e21a23e8a8191ba722225fd OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9143e68df06302ee9a19e21a23e8a8191ba722225fd88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HCD7upGFpVahXGqF7QWZZfZry4nRfHJk8P"
]
}
}
]
}

---

**Decoded second confirmed transaction that caused conflict
55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086

---

{
"txid": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"hash": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"size": 103,
"vsize": 103,
"version": 553216,
"locktime": 0,
"vin": [
{
"gametx": {
"player": "hof",
"op": "spawn_death"
},
"scriptSig": {
"asm": "6713192 OP_NAME_NEW",
"hex": "03686f6651"
},
"sequence": 4294967295
},
{
"gametx": {
"player": "labi",
"op": "spawn_death"
},
"scriptSig": {
"asm": "1768055148 OP_NAME_NEW",
"hex": "046c61626951"
},
"sequence": 4294967295
}
],
"vout": [
]
}

change address reuse and transaction time

In the past version of huntercoin we had by default the addressreuse setting that caused any transaction to give back the change to the same address, now is this feature with huntercore lost?

It seems that with a 20MB wallet of transaction, moves takes lot longer to be accepted (seconds) and with current block generation time so variable, there are many times a new block generate after few seconds, causing the move to go in blockchain after 3 blocks, screwing the gameplay (and i suppose this is what happened to other users that posted on the forum)

Is this because of no address reuse and so lot of unspent transactions are used? anyway the wallet is slow when he reach around 15/20 mb (non SD drive) and this would cause players to have to create new wallets very often

Cleaner JSON format for characters in game state

Currently, the JSON format for hunters/characters in the game state is messy - the "player state" object contains certain fixed keys like value or color, but also the individual character states are there directly with keys like "0" or "42". This makes parsing on the client side harder, as one has to check each key either against a hard-coded black list of known fixed keys or for being a valid number formatted as a string in order to determine which character states are present.

We propose to change the format such that all character states are moved to their own subobject characters, so that it is easy to enumerate all characters of a player (by just going over all keys of the subobject).

In other words, let's change this:

"domob": {
  "color": 2,
  "value": 1.00000000,
  "0": {
    "x": 263,
    "y": 442,
    ...
  },
  "1": {...},
}

To this:

"domob": {
  "color": 2,
  "value": 1.00000000,
  "characters": {
    "0": {
      "x": 263,
      "y": 442,
      ...
    },
    "1": {...},
  }
}

This change requires all front-end software parsing the game state to be updated, but will make the parsing there simpler. Until all users are updated (e. g., after the next hard fork has taken place), client software can support both formats by checking for the presence of the characters field. In addition, we will update the client version (version in getinfo output) with this change.

Malformed coinbase field when using rest interface to retrieve block

Hi,

when using the rest interface to retrieve information on a block, the coinbase field in the coinbase transaction appears to be malformed.

Example for genesis block:
The call curl http://localhost:8399/rest/block/00000000db7eb7a9e1a06cf995363dcdc4c28e8ae04827a961942657db9a1631.json returns
"4ce30a48756e746572636f696e2067656e6573697320746..." as coinbase. Not only is the value incorrect, it also has the wrong size (far to large).

Built from source on branch 'master' (last commit: 68a71e0) .

new wallet problems

I have to report a problem that afflicted me already a couple of time
this happen when i create a new wallet and this is what's happening:

I have a game wallet (wallet.dat) and i want to create a new one to start with an empty a fresh wallet (faster game)

• I rename the wallet.dat to walletOld.dat
• I restart the client and it creates a new wallet.dat
• I write down one of his address and stop the client
• I rename wallet.dat (the new one) to walletNew.dat
• I rename walletOld.dat to wallet.dat
• I restart the client (so using the old wallet) and transfer funds to the address i wrote earlier (so to the new wallet)
• I stop the client and rename again both wallet and then i start the game

at this time, the new wallet has received the funds (suppose 10000 HUC) , so i start creating hunters, but... here "magic happens"...

• i create 5 hunters (funds around 9500) and i start moving them, then some of them got stuck, and balance draw near to 0, i get a lot of conflicts tx and hunters that could be moved, can't be moved because the wallet says i've no money (but i have... i should have around 9500)
  I restart the client (huntercore) a few times, than finally something unlock and balance come back

this already happened to me 2 times with different wallets, If i find the time tonight i'll try to create a new one and maybe posting the debug.log or some other info, do you have any clue about the possible cause (note that i tried both to enable and disable the "use unconfirmed changes" (not sure if this is the right label, i see the wallet in italian) to see if this was related