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

P.S.
I'm downloading blockchain from chain.huntercoin.org
I was thinking that to save space, bandwith and time, you could add just modified files
blk001.dat, blk002.dat, blk003.dat and blk004.dat sholdn't change, right?

so you can leave current zip as a base, then add just file that need to be overwritten, what do you think?

(i'm talking just for full blockchain)

According to my theory (see my post for more details, it is somewhere in there as well), the initial problem arises due to the double-spending thing I suspected already some time ago.  However, fixing it locally for you with name_clean doesn't fully solve the problem, due to other nodes still keeping the wrong transaction.  This is what I think we have to fix - clear the mempool on each new block by removing such transactions automatically.  I'll give the code a look soon to decide about the best implementation.

this makes sense about the deletetransaction and you could be right about that problem, but why it should stay at no confirmation state at first place even if i don't call deletetransaction?
maybe the system call deletetransaction or some equivalent on other transactions that share one of the input that the killed player transaction had?

since the stuck problem doesn't seems to happen everytime (or at least i think), maybe the problem is that there is something that goes wrong where 2 transaction share one of the input address?

@MithrilMan:  No, you need not upgrade from one version to the next.  The error you are getting sounds like a corrupted utxo.dat.  Try shutting down the client, removing utxo.dat and restarting.  This will recreate it - but it takes a long time.  Alternatively, you can try to revert to my blockchain download or a backup (but only if you know that the backup it clean).

Regarding the pending issue:  Thanks to bigminner, I looked at some wallets that indeed showed strange behaviour.  This is most probably "only" an issue with relaying / mining the transactions, not the double-spending one.  (The latter is still actually possible when hunters get killed and you have to clear transactions of them, and it should be fixed by "name_clean".)

I've got a suspicion about what the problem is, and have written a small patch that gives extended debug log to test it.  It takes some time for my VPS to fill its mempool, though, so I can't know for sure right now.  Hopefully in some time.

In short, I suspect that the problem is that if you "deletetransaction", then this only removes the tx from your own node.  If others still have it in the mempool, this is not cleared.  When you then try to re-create the tx, it is considered a double-spend and not relayed / mined.  Maybe it is even a combination of both problems:  The initially stuck transaction is created due to the already stated double-spending issue (player death).  You can fix it locally for yourself by deleting the transaction (or letting "name_clean" delete it for you), but other nodes don't delete the tx even though it can never confirm anymore.  You also can't respend the coins, since the other nodes block it.

If this suspicion is confirmed, the fix should be to make "name_clean" (or an equivalent action) be performed automatically on the mempool by all nodes - then, when every relaying node plus miners upgrade, it should prevent this from happening again.

p.s. anyone tried name_clean yet?

REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1a2d5230, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1e9ffee0, pnext=00000000, nFile=4, nBlockPos=2093906621 nHeight=346125, merkle=461a3f4790, hashBlock=75fe44df718000785fb2)
  Common: CBlockIndex(nprev=1a2d5230, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=75fe44df718000785fb2  height=346125  work=207112889955601132511996
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
InvalidChainFound: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 245133d97f0c10008952

ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
InvalidChainFound: invalid block=bc301272d8e00c26632a  height=346023  work=206931702201427835251197
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : ConnectBlock failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 9fdad33fd0853f39b6ec
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f8077f0, pnext=00000000, nFile=4, nBlockPos=2093386035 nHeight=346024, merkle=1e7bf626a7, hashBlock=9fdad33fd0853f39b6ec)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=9fdad33fd0853f39b6ec  height=346024  work=206931767448775230994941
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
connected 192.210.135.154:8398
received block 50c4bf3f81b1328bc188
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f807900, pnext=00000000, nFile=4, nBlockPos=2093388707 nHeight=346025, merkle=2b3f4fac17, hashBlock=50c4bf3f81b1328bc188)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!
InvalidChainFound: invalid block=50c4bf3f81b1328bc188  height=346025  work=206931832645508852967933
InvalidChainFound:  current best=4d062bd0b387b1da2dad  height=346022  work=206927836026554670104633
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 51c80e9170f1a61925c1
REORGANIZE
Reorganize():
  Old: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
  New: CBlockIndex(nprev=1f807878, pnext=00000000, nFile=4, nBlockPos=2093394648 nHeight=346026, merkle=8757b60982, hashBlock=51c80e9170f1a61925c1)
  Common: CBlockIndex(nprev=1b2a3a48, pnext=00000000, nFile=5, nBlockPos=77550944 nHeight=346022, merkle=83713911a3, hashBlock=4d062bd0b387b1da2dad)
ERROR: ConnectInputs () : c2724483af3f7c85fd277b63af087be2238fda825015ecb527759bb40815cb9d failed to find prevout COutPoint(c93fdf5e82, 1) in UTXO set
ERROR: Reorganize() : ConnectBlock failed
ERROR: Failed to abort child transaction in NameDB!

have you tried name_clean?

the double-spend btw, this isn't some hack that allows people to spend coins twice, as it may sound. Some people have hunters which get stuck..
If you get the pending problem, use name_clean

none of the patches make a difference to the pending problem - you need to manually attempt to fix with name_clean.

give us feedback - this patch has been out for a long time and not one person has said whether it works or not

If it works, Domob can allow it to run automatically.

It is the wallet stuck of spending(sometimes shows "spending rejected"), not double spending of the whole system.

double spending?

If the pruning and double spending are solved(still not solved in 1.011g), there will be more players in this game.

About bots starting when disaster happens.. we already thought and said that would happen before we implemented it (written on forum somewhere).
It's an issue, but I think it's not as bad as it seems. In reality they can only guarantee get the easy coins in their own quadrant. The rest is up for grabs if you have enough and can attack.
Open to ideas..
One solution was that you maybe spawn in random locations for the next X blocks after disaster -- it may make the easy coins harder to get (if you start on the opposide side of your normal spawn area for 100 blocks?)..  not sure if a good idea - needs more thought.

Checking in guys. Never heard of huntercoins until recently. What are some good things going for it?

BGB got a 1000 or 2 (maybe he can say the exact amount) just by being first in line after a disaster.  And that was just around the edges.  I just think the disaster serves bots even more than before if it is like this.   I dont want to seem like I'm complaining or jealous.  I have bought a shitload of HUC, and play for fun.  Just want to help make it better and make suggestions so that they become more valuable in the future.

meanwhile a disaster is just happening
while a fight blue vs yellow was going on in the middle lol