chronokings/huntercoin

Human-mineable crypto currency / decentralized game

huntercoin's Issues

problem with transaction changes

Something strange is happening.
this is the address of my game wallet:
http://huc.explorer.dot-bit.org/a/HV7GW3vJvvHoJqixE2FwN3cLhBVWqkj2Pe

this is an example of the transaction that's generated
http://huc.explorer.dot-bit.org/tx/b43495ae3fbad9b645eb7ecdacfc97b49557a3f411f3f80453245fa3cc896a18

problem is that in my client i see a lot of weird transaction, one for each update i do, that have the "received" type, and it's just the change of the name_update transaction, that goes to one of the address i've in my address book, so i think it's showed because of this, and this happen because of address reuse (am i right?)
anyway it's weird and those kind of transaction weren't showed previously

moreover, now after all this transaction (when i see something like 3.5 huc received) now my address report that i've more HUCS than what i've for real (game_info report the correct value for my wallet)

ideas?

RPC request: tx decode

need an RPC command to return a decoded tx given whichever transaction id

old wallet to new wallet. using samewallet.dat or importing privkeys

sorry if this may seem trivial but i have 10k+ transactions that i had in the old (first) wallet prior to you moving over to the name coin/bitcoin client. all incoming and no outgoing transactions. when i search those addresses on the block explorer they say the address does not exist however i can import thos privkeys into the new huc client and then nothing shows. i understand it has been a while but i cameaccross an old hdd with the block data and a wallet.dat can you assist me on how to recover the funds from the old clients.
last client version i had was 1.4.0

add an RPC command to force a rescan without having to restart the daemon

now that i succeeded at reading keys in wallet.dat, would be nice to have a way to force a wallet rescan without having to restart the daemon

what i want to do in my client is giving the chance to the user to pick a wallet, and import all its keys into the wallet current running within huntercoind
this allow to recover compromised wallet or join multiple wallet into one.
I know importprivkey has a parameter to force the rescan, but since the user can manually import single keys too, i want to give him the ability to force a rescan as an indipendent command, so if he forget to add the "rescan" parameter to his last importprivkey he can anyway rescan the wallet.

this command could even be useful to force a rescan after having deleted a pending transaction

this rpc command could be done simply as a command that return once it has finished, or more complex (but more useful for a feedback to the user) as one command to start rescanning (that return instant) called e.g. "rescan" and another to check it's progression, like "rescan_status" that could return the % of scanned blocks, or 100 (or another value) to specify rescan isn't running

pending issue

ok, people reported pending transactions problem and i faced them right yesterday while i was playing

here facts:

• i was playing, i sent a name_update to move TWO of my hunters (generals both) but one of them got killed the next block, before transaction had confirmation
• one of my RPC call fails (i use gettransaction to see transaction status and confirmation, see ending note) saying that transaction wasn't available ("ok, no problem" I thought, that transaction isn't visible anymore because i've been killed)
• problem is that the other hunter (the alive one) didn't get confirmation neither, standing forever in a pending status
• from that point, i've had strange wallet behaviour (with other transaction getting pending forever)

now i've added a "Delete Transaction" in my client but that didn't sove the issue because you'll have to restart client and it's not guaranteed that the problem will be fixed

i think we have a problem here with incorrect transaction, could you check what happen when "gettransaction" try to get a transaction about a killed player with no confirmation (btw don't think the problem is there) and what happen if player is killed while he has pending moves?

don't know if the problem is only about RPC or even standard client is affected
I'll try to reproduce on testnet, anyway it seems to be an important issue to get fixed

P.S.

• note that my client store all pending operations in an inmemory list and check every game_state if those transaction are in pending (0 confirmation) or not, then if the transaction is confirmed i trigger some client actions depending on the type of the transaction (name_new, name_firstupdate or name_update) so i have to keep that inmemory list

to check their status i call gettransaction passing the tx id of the inmemory pending operation, this cause the RPC exception when i try to ask a transaction of a death player (it's fine, talking about code flow, because then i remove it from the list, but don't know how that exception cause some problem in the wallet/daemon)
(don't tell me to use name_pending for that because i still have to know when a transaction has been confirmed because i trigger some actions, so i need an inmemory list).

RPC game state has incorrect unicode characters

when game_getstate is fetched, chat messages have wrong formatted unicode chars
I can't get correct extended characters like chinese, cyrillic, etc..

About Huntercoin Core

I'm sorry for writing in wrong place, but could you allow reporting issues in repository https://github.com/chronokings/huntercore?

The problem with the new client is that there's too many references to Namecoin - so it tries to use the same catalog and registry entries as new Namecoin Core, and I cannot run them side-by-side.

name_pending lock and wallet transactions problem

It seems to me that a big problem is about wallet having many transactions.
currently the system isn't scalable (talking about RPC but i guess it impact qt too) because there are many locks around, and i suppose some operation dealing with wallet transactions locks code for too much time

locks should be used very carefully because it can impact a lot on the overall system, so i'm trying to browse a bit the code to see if i see something strange, unluckily i'm not able to have an environment that works on my pc to test things

ok now the point of my question:
I'm trying to use name_pending constantly to try to keep an eye on incoming transactions, and i noticed that many times it "hangs" for up to 25/30 seconds before returning

looking the code, i see that "you" used two locks (i suppose CRITICAL_BLOCK are locks)
CRITICAL_BLOCK (cs_mapTransactions)
CRITICAL_BLOCK (cs_main)
{
you then do all the logic here
}

i ask why having those locks?
this procedure has just to dump inmemory things as far as i know (memorypool) so why it should need locks?
if it's because of multithread, then the lock should be used just to get a snapshot of current memorypool tx and release it asap and i suppsoe that cs_mapTransactions is the lock about memory pool, but why it need even the cs_main?

i don't know which lock is currently involved on the problem about having too much wallet transactions (do you know where the problem can lie? there are parts in the code that need to look into the whole transaction a player has, every block??)

I think that "wallet performance" is an issue that should be taken into consideration, because it would cause users to keep creating new wallets often (as i have to do to be better performing and don't have big stuck problems)

any clues?
can you give it a try about removing or using differently those locks on that function?

note: after my system receive a block, the name_pending will have a big delay for many seconds (how much i think depend on transactions in my wallet) and after a while (25 seconds more or less, in my case) it then is again responsive, until next block generation

Send change back to the same name (already used) address

Originally name_updates did not change the address of the name (general/team)-
adding fees now requires change to be sent back to the wallet (using up another address from keypool)- this uses up the keypool

This should allow less frequent backups (for heavy players)

Need an RPC command to get a RAW transaction minimum fee

Need an RPC command to get the minimum fee required to create a raw transaction
this way, using daemon would be easier to generate transaction without putting insufficient (or too many) fees

i think min fee should be available as RPC command because it's a daemon responsability to know that

P.S.
don't know if it's already available, but sendrawtransaction should check if the minimum fee has been used in the transaction

need to know daemon status when used as -server

it would be quite important from an user perspective, I'll try to explain the typical scenario

When the user launch my client (call it HUC:ME), it read user settings looking for the name of the huntercoin process to launch (it can be huntercoind.exe, or huntercoin-qt even it has limitation and i discourage, i just use sometimes while testing things, or it may have a totally new name because of a custom build or whatever)
I check then if the system is already running a process with that name:

1. if it found the running process, I try to use my user RPC settings to connect to it
2. if no process found, then i launch that one with custom arguments taken from user settings

At this point, if case is 1 maybe the daemon is already ready to communicate, so if i can't, this could be a misconfigured client (in case of wrong name/password i get a specific exception that i can handle, but if the address is wrong i can't, so in this case i suppose that if i don't get response from that process, it's unresponsive and i kill it and restart (going to poin 2). knowing real state could help

If i'm at point 2, i've just launched the daemon process so now it's unresponsive till it ends its initialization stuffs that may takes some minutes
being unresponsive, i can't tell the user if it has some wrong settings or he has just to wait, and i can't really tell the user anything, he has just to work out himself

different things could go wrong, eg a wrong -datadir setting specified as optional command line (see pic), or wrong daemon path/filename, daemon crash because of insufficient space, etc...
this is an example of the settings window:

you can see here how i configure argument i pass to the daemon when i launch it (I add already by code some other like -server)
As you can see I've even added a "Test Daemon Settings" and i'd love to use it to do all possible checks, but at the moment i just do a check about correct daemon path, nothing more
would be nice, if you can't enable RPC very soon, to be able to call a daemon with a new argument like -testconfiguration where it just return a code indicating if the settings issued are correct or not

e.g. if i call

huntercoind.exe -server --rpcuser=username -rpcpassword=password -datadir=C:\blockchainlocation

it should return an error code about wrong rpc password or datadir, etc...
I'm not sure if exists a way to test RPC address, maybe RPC port would be enough

thinking about it, maybe an easy solution would be to create a file called currentRPCstatus.log where you just write a line in it, updating current status, going through:
if all ok, two statuses

• "initializing"
• "ready: RPC-Port:8999"

if it has problems, those statuses:

• "incorrent datadir"
• "could not open port xxxx"
• ... anything useful

it has to be recreated every time the daemon is launched, and has just to hold one line. would be best if it is formatted in JSON, eg:

currentStatus:{ "status": "ready", "RPC-Port":8999 }

click to go to the discussion post

Qt unresponsive during network operations

The client is unresponsive during network operations like "Flushing wallet.dat" and "askfor block".

Need to integrate QCoreApplication::processEvents() or something similar so that events can be interrupted to process user input.

Reference:
http://doc.qt.digia.com/qq/qq27-responsive-guis.html

blochain upload

Sync is too slow, and can't mine over new huntercore... Can you upload blochain for usual client ?

wallet constant activity

ok, after having posted an issue abound name_pending i tried to dig a little more and i see that the most activity is on the wallet file !?

an average activity on my actual wallet (~94MB) is this:

= ~ 5 MB/sec of activity on wallet, why? what did it have to keep writing in wallet continuously?

and things goes even worse, here i've peeks like this

where it reached 8MB/sec of activity in the wallet file (in the screenshot were 6+)

this comes out form perf mon, need to observe it with another tool but things are that actually the wallet is constantly read/written, not just when blocks comes, why this constant access? couldn't the activity be cached and wrote at once ?

without consider how bitcoin wallet works, for a game wallet this is too much disk activity for unknown (for me) reason

Add GetBlockTemplate & SubmitBlock

Need those to start putting pools up. Please consider it and thanks.

Major Fragmentation on windows

I believe it's down to the issue described here

bitcoin/bitcoin#776

possibly a solution is in there too.

-- with mechanical hard drive - causes insane client slow downs and major disk access, of which gets worse over time.

error: ‘MiddleButton’ is not a member of ‘Qt’

g++ -c -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2 -D_REENTRANT -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -Wno-sign-compare -Wno-return-type -Wno-char-subscripts -Wno-switch -DGUI -DQT_GUI -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DNOPCH -DFOURWAYSSE2 -DUSE_SSL -DUSE_QRCODE -DLINUX -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Isrc -Isrc/json -Isrc/qt -I/usr/local/boost-1.55.0/include -I/usr/local/db-5.1.29.NC/include -I/usr/local/openssl-1.0.1h/include -I/usr/local/qrencode-3.4.3/include -Ibuild -Ibuild -o build/gamemapview.o src/qt/gamemapview.cpp
In file included from src/qt/../gamemovecreator.h:6,
from src/qt/gamemapview.h:4,
from src/qt/gamemapview.cpp:1:
src/qt/../gamestate.h: In member function ‘unsigned int Game::LootInfo::GetSerializeSize(int, int) const’:
src/qt/../gamestate.h:161: warning: unused variable ‘fGetSize’ [-Wunused-variable]
src/qt/../gamestate.h:161: warning: unused variable ‘fWrite’ [-Wunused-variable]
src/qt/../gamestate.h:161: warning: unused variable ‘fRead’ [-Wunused-variable]
src/qt/../gamestate.h: In member function ‘unsigned int Game::CollectedLootInfo::GetSerializeSize(int, int) const’:
src/qt/../gamestate.h:193: warning: unused variable ‘fGetSize’ [-Wunused-variable]
src/qt/../gamestate.h:193: warning: unused variable ‘fWrite’ [-Wunused-variable]
src/qt/../gamestate.h:193: warning: unused variable ‘fRead’ [-Wunused-variable]
src/qt/../gamestate.h: In member function ‘unsigned int Game::CharacterState::GetSerializeSize(int, int) const’:
src/qt/../gamestate.h:215: warning: unused variable ‘fGetSize’ [-Wunused-variable]
src/qt/../gamestate.h:215: warning: unused variable ‘fWrite’ [-Wunused-variable]
src/qt/../gamestate.h:215: warning: unused variable ‘fRead’ [-Wunused-variable]
src/qt/../gamestate.h: In member function ‘unsigned int Game::PlayerState::GetSerializeSize(int, int) const’:
src/qt/../gamestate.h:273: warning: unused variable ‘fGetSize’ [-Wunused-variable]
src/qt/../gamestate.h:273: warning: unused variable ‘fWrite’ [-Wunused-variable]
src/qt/../gamestate.h:273: warning: unused variable ‘fRead’ [-Wunused-variable]
src/qt/../gamestate.h: In member function ‘unsigned int Game::GameState::GetSerializeSize(int, int) const’:
src/qt/../gamestate.h:343: warning: unused variable ‘fGetSize’ [-Wunused-variable]
src/qt/../gamestate.h:343: warning: unused variable ‘fWrite’ [-Wunused-variable]
src/qt/../gamestate.h:343: warning: unused variable ‘fRead’ [-Wunused-variable]
src/qt/gamemapview.h: In constructor ‘GameMapView::GameMapView(QWidget_)’:
src/qt/gamemapview.h:71: warning: ‘GameMapView::scheduledZoom’ will be initialized after [-Wreorder]
src/qt/gamemapview.h:37: warning: ‘const GameGraphicsObjects_ GameMapView::grobjs’ [-Wreorder]
src/qt/gamemapview.cpp:382: warning: when initialized here [-Wreorder]
src/qt/gamemapview.cpp: In member function ‘virtual void GameMapView::mousePressEvent(QMouseEvent_)’:
src/qt/gamemapview.cpp:657: error: ‘MiddleButton’ is not a member of ‘Qt’
src/qt/../serialize.h: At global scope:
src/qt/../serialize.h:39: warning: ‘pszSubVer’ defined but not used [-Wunused-variable]
/usr/local/boost-1.55.0/include/boost/system/error_code.hpp:222: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable]
/usr/local/boost-1.55.0/include/boost/system/error_code.hpp:223: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable]
/usr/local/boost-1.55.0/include/boost/system/error_code.hpp:224: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable]
make: *_* [build/gamemapview.o] Error 1

Tool Tip for New Player still says 1 HUC

Hovering over "New..." in QT
says "player cost = 1huc + fee"