Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by DarkClaw

  1. This sounds like an issue I did have a few days ago but should be fixed now. I just registered "p/myname" and it showed up a little later (see attached). Are you visiting the domain, ie https://www.xaya-gaming.net/? I think if you visit the ip address ( ) directly it breaks now for some reason. All that works for me is the chart and mining calculator. So maybe you saved that in your bookmarks? If thats the issue I'll make a bigger note in the OP and replace that link.
  2. Just a note. Right now the desktop site is much more stable than the mobile site. So if you have trouble with any features on mobile (eg looking up a name) please try it on desktop instead.
  3. I'll check it out. How I was doing it is checking hash[idx] == prev_hash[idx + 1], then if it was false compare hash[idx] to all prev_hash[j] (j in 1:nBlock). If they are all false its an orphan, if not I would store the idx and j indices, eg I have a table like this (this is just partial, so they may not all pair up): idx_hash idx_prev_hash 17312 17314 17313 NA 17353 NA 17377 NA 17413 NA 17653 NA 17743 NA 17753 NA 17778 NA 18142 NA 18199 NA 18540 NA 18556 NA 18690 18727 18726 18728 18727 18729 18728 18730 18729 18731 18730 18732 18731 18733 18732 18734 18733 18735 18734 18736 18735 18737 18736 18738 18737 18739 18738 18740 18739 18741 18740 18742 18741 18743 18742 18744 18743 18745 18744 18746 18745 18747 18746 18748 18747 18749 18748 18750 18749 18751 18750 18752 18751 18753 18752 18754 18753 18755 18754 18756 18755 18757 18756 18758 18757 18691 18775 NA Using the first row, I'd resort the blocks as: 1:idx_hash[1], idx_prev_hash[1], ((idx_hash[1] + 1):nBlocks)[-idx_prev_hash[1]] And then I'd recalculate the table (which should be 2 rows shorter now) and keep doing that until there are only orphans left. This solution is not very efficient and incomplete since it will fail if there is an orphan chain (rather than just a single block), amongst other issues. It is more a prototype to help me wrap my head around the problem. But anyway you can see why I was thinking of "sorting algorithms", I'm sure in the end I will end up using the existing method. Edit: I can't write hash[i] in the main text, its being read as an italics tag. Not a big deal but itd be cool to have an "inline code" tag to prevent this. Maybe it exists already...
  4. Speaking of which, how many huc should exist right now? I'm not sure these block explorers are correct (I don't have my own huc chain to check for myself at the moment). If block reward started at 10 huc per block and halved at block 2,100,000, then at block 2,381,326 (today) I get: (2.1e6*10 + (2.381326e6 - 2.1e6)*5) = 22,406,630 Perhaps its only the miner reward that halved (from 1 to 0.5 coins) while the game reward stayed the same (at 9 coins)? But either way shouldn't "generated" here be 0.5: https://www.huntercoin.info/blockExplorer/block/b115e00c59ba604522a23299abcc6812ab995a86a7d71f084bab025d8e124368 https://chainz.cryptoid.info/huc/block.dws?b115e00c59ba604522a23299abcc6812ab995a86a7d71f084bab025d8e124368.htm That second explorer also claims there are 80 million plus huc at that block: Maybe it is just dealing with HUC incorrectly: https://chainz.cryptoid.info/faq.dws Then there are strange blocks like this: https://www.huntercoin.info/blockExplorer/block/d4a1d8895a9e50a434dc559b4cbb7eeab07cca88d1b815402dda2ff606208469 https://chainz.cryptoid.info/huc/block.dws?d4a1d8895a9e50a434dc559b4cbb7eeab07cca88d1b815402dda2ff606208469.htm Is the HUC market cap actually 4x higher than usually thought?
  5. https://www.huntercoin.info/blockExplorer The site is up, but you need to add an exception.
  6. Seems to work fine, also that awful flashing due to a low refresh rate (or whatever it was) has stopped.
  7. Thanks. That makes sense, I'll have to check out how the index is being built too. It seems like there should be a name for this sorting problem and some common algorithms people use...
  8. Great, of course you need to test it before people lose their coins... But once you are set up for one coin I imagine its pretty straightforward to do another.
  9. /** Size of the "block download window": how far ahead of our current height do we fetch? * Larger windows tolerate larger download speed differences between peer, but increase the potential * degree of disordering of blocks on disk (which make reindexing and pruning harder). We'll probably * want to make this a per-peer adaptive value at some point. */ static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024; https://github.com/xaya/xaya/blob/2e25715a3a0e7abd8951313b410810d9f3fc4893/src/validation.h http://learnmeabitcoin.com/glossary/blkdat I have whats probably another crypto dev 101 question. Does this mean if I am parsing the blk*.dat files, I only need to look +/- 1024 blocks to find a block with the previous hash corresponding to the current hash? Ie, if no hash is found in that window then it is an orphan? Currently the biggest offset I see is 67 blocks... Also, is it possible for me to somehow ensure I only download the blocks in order even if that means my chain is slightly (eg 5-10 minutes) out of date?
  10. Thanks, sounds good. Do you plan on adding huc too at the same time? Surely it is not really as simple as adding one of these json files: https://github.com/trezor/trezor-common/tree/master/defs/coins Is it?
  11. Can one of the devs get xaya support added to trezor? https://trezor.io/coins/ I searched a bit on how to do this and, apparently, it is not too difficult: https://www.ccn.com/crypto-wallet-trezor-adds-support-for-fictional-currency-piedpipercoin/ Also, perhaps get huc on there as well?
  12. Thanks, as you can see we haven't worked that out yet. For now you can donate chi here if you want: CZTUk53bma957yqaaKt5Ts9SJjLPfPPbte Or bitcoin here: 16SifYv2q58vydDrwvxxvCYyCtYpb1bPf8 If you do that, please let me know your intentions. Eg, if you mean for me to pass on half to capo0r, etc.
  13. Does it still happen if you lower the intensity? Eg, add the flag -i 5 to set intensity lower, then if it works increase it until you get the error or ccminer crashes.
  14. Makes sense and sounds good, thanks.
  15. At first I thought it had something to do with not paying a high enough fee? In what way is it too large? Actually a cool feature for the wallet would be to tell me how many kb the transaction I am about to initiate will be.
  16. I just tried to consolidate 100 coins I mined to my game wallet to a single address in my vault wallet and got a "Done: transaction too large". Nothing was sent. 1) If the transaction didn't go through it should not say "Done", it should say "error" or similar. 2) What is going on here? What is "too large"? Did I fall afoul of one of these? https://github.com/xaya/Specs/blob/master/blockchain.md
  17. Not sure what it has to do with the wallet synchronization but shouldn't that say neoscrypt instead of bitcore?
  18. Thanks. Thanks, obviously there is a lot more to add to this. Ie searching for an address/tx/name etc, but we figured just being able to easily and quickly inspect the overall status of the network is really important to people. Also there may very well be bugs so if anything looks off please tell us.
  19. Thanks. Actually I just tried it on mobile for the first time and saw (that even worse) the "todays stats" main table was cut off. So I think it is definitely not mobile friendly at this point but have no idea how difficult that would be to fix. It sounds like a good idea to me but I'll leave that answer to casp0or.
  20. About a week ago I made a post on this forum regarding calculating some basic mining stats and fellow Xaya fan casp0or offered to help me out in doing a front end for it. It is still a work in progress but we think it is ready for some public feedback. I heard for some reason our domain name is delayed so you can visit the site here for now. (2018/08/03: please use https://www.xaya-gaming.net/, note the "www" must be included at this point) At this point it provides basic info about the blockchain like block height, number of registered names, etc. It also shows a block by block chart of the difficulty for both NeoScrypt and SHA-256d algos and daily data on a number of stats like average hashrate, block size, etc. Beyond that there is also a mining calculator so you can estimate how many coins you could expect to mine by adding your miner to the network. Please share any criticisms and suggestions you have so we can improve on it. Of course, also let us know what, if anything, you find most useful about it. See attached for a screenshot: EDIT: Here is the current domain: https://www.xaya-gaming.net/ 2018/08/03: Please note the "www" must be included at this point, ie http://xaya-gaming.net/ will not be fully functional.
  21. Yes, you can register as many names as you want as long as it is not already registered.
  22. Thanks. Somehow I did not think to scroll... Also is there a guide to making a xaya.conf? Eg, is this good enough? # If no rpcpassword is set, rpc cookie auth is sought. The default `-rpccookiefile` name # is .cookie and found in the `-datadir` being used for bitcoind. This option is typically used # when the server and client are run as the same user. # # If not, you must set rpcuser and rpcpassword to secure the JSON-RPC api. The first # method(DEPRECATED) is to set this pair for the server and client: #rpcuser=Ulysseys #rpcpassword=YourSuperGreatPasswordNumber_DO_NOT_USE_THIS_OR_YOU_WILL_GET_ROBBED_385593 https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/examples/bitcoin.conf Thanks, I also found this description later on and it was helpful: https://github.com/xaya/Specs/blob/master/blockchain.md
  23. I understand that the focus needs to be on developing xaya now, but I think this looks pretty bad promotion-wise, especially when it just seemed to be getting some volume: https://poloniex.com/exchange#btc_huc Regardless of how much you care about it directly, Its important that HUC at least remains functioning for the sake of xaya since it is mostly the same team . Is there any info on this, is it a poloniex only problem?
  24. DarkClaw

    Mining Stats

    Looks like this was a bad assumption, it increases up to 128 MiB in 16 MiB intervals before creating another file: /** The maximum size of a blk?????.dat file (since 0.8) */ static const unsigned int MAX_BLOCKFILE_SIZE = 0x8000000; // 128 MiB /** The pre-allocation chunk size for blk?????.dat files (since 0.8) */ static const unsigned int BLOCKFILE_CHUNK_SIZE = 0x1000000; // 16 MiB https://github.com/xaya/xaya/blob/90111e2b4b2631a1df56df60a656ea820021cba7/src/validation.h
  • Create New...

Important Information

Your use of this site is governed by our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.