Jump to content


Dev Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by domob

  1. domob

    Price Drop

    I don't think that I can speak "for the team", nor is that my expertise (which is blockchain development and the technical side of Xaya). From my point of view, it would be great to have a higher price - I do hold some CHI personally, and also of course the team is the biggest single holder with the reserved 10% company coins. But I think it is definitely more important for the project at large and also for the long-term price to concentrate on building out the platform as well as cool games for it, rather than concentrating on the market price and trying to pump that. Xaya is not a copycat coin that we want to pump for a quick money grab, but a technological vision we want to realise. That is what the ICO participants gave us money for.
  2. No, not really. That seems not too far off, though, so I guess it is just due to fluctuations in the hash rate or something like that.
  3. If I see it correctly, your method works off the current difficulty only. The method used in the RPC actually calculates the hash rate over a previous period of time, based on the individual difficulty values of the blocks (e.g., it handles changes of the difficulty over time). There is no particular reason why I did it that way, except that this is also how upstream Bitcoin works - except that I had to extend the logic to handle multi-algo correctly.
  4. domob

    CHi for sale (no KYC)

    I can also vouch for Bisq - used it for BTC / fiat trades myself some time ago. As far as I understand, it is easy to get listed there as an alt, but then you get delisted if there is not enough volume. So I don't know if it is worth the effort right now or if it would just get delisted again.
  5. domob

    About Soccer Manager Crypto

    Currently it is still in a private repository while it is being built, but it will be made public with the release of SMC.
  6. domob

    About Soccer Manager Crypto

    In addition to what @snailbrain already said, note that the platform-dependence will only be for the front-end / UI. The backend, which runs the actual game on the blockchain, will be free software and cross-platform (being developed actually on GNU/Linux) from the start. That means that at least technical users and developers interested in building something in the ecosystem will be able to make use of it immediately if they want.
  7. Yes exactly, "getinfo" should be replaced with "getnetworkinfo", " getmininginfo" and "getwalletinfo". "listaccounts" should be replaced with "listlabels", and "getaccountaddress" with "getnewaddress". Not sure why the pool would need "move" at all, accounting in the Bitcoin wallet has been deprecated for a very long time (and never really worked actually).
  8. Since Xaya is not just a blockchain project but a platform for blockchain games, we are not only working on the core blockchain infrastructure but also additional layers that make it easy to develop fully decentralised games. The first step in this direction is the game-specific ZeroMQ interface we designed, whose main parts are already implemented and tested in the Xaya Core daemon. Using this interface directly, however, still requires messing around with potentially unreliable ZMQ notifications and handling of blockchain-specifics like reorgs. Thus, we are also building libxayagame: A library that interfaces to the core daemon through the ZMQ interface and handles all the blockchain-specific processing. This makes it super easy to develop fully decentralised games on the Xaya platform, without any prior blockchain experience or knowledge. All you have to do to implement a game is to provide functions that implement your game rules; namely by computing a new game state from the old state and a set of moves. The library then handles all the rest for you. This is still very much a work in progress with lots of missing pieces before it can be used in production, but it can already be used in development and early testing. So if you are interested in developing a game on Xaya, I strongly encourage you to take a look at libxayagame and the integrated example game "Movers". It can probably save you a lot of messing around with ZeroMQ, blockchain reorgs and other stuff.
  9. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    Well - you can certainly build blocks yourself and submit them right now if you follow the specs. The only reason why you need the fork is because apparently the current restriction of "nonce for the actual header has to be zero" is in conflict with how the Stratum protocol works; but I may be wrong here.
  10. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    I think you can use "getwork". It will return you a work that corresponds exactly to this "fake block header" you need to solve. So as long as you get your pool miners to solve the work somehow (as an ordinary Bitcoin block header, basically, except of course with Neoscrypt), you can submit it afterwards. However, if you use "getwork", then I think you won't be able to get the real block header / pass it as coinbase transaction to the pool miners. I don't know enough about Stratum to tell whether or not that is a problem. I think the miners that I talked to previously planned to call "getblocktemplate" and build the block header as well as the PoW data and stuff themselves, so they have full control over it. As far as I know, that will at least after the fork work for sure.
  11. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    Thanks for your work on this! Again, as I understood the discussion with other miners originally, you seem to be on a wrong path here. For Xaya Neoscrypt mining, there is a "fake block header" that has the actual PoW and commits to the real Xaya block header through the Merkle root field. So your Stratum miner would never even see the real Xaya block header (with the things you quoted above), it would only work on that fake header. The real Xaya block header would be seen by it like a coinbase transaction, which is also linked to the block header through the Merkle root field. And that's where the extra nonce comes in: For Bitcoin mining, the extra nonce is part of the coinbase transaction - so the Stratum protocol requires some field in that data (which for Xaya is the real Xaya block header) that the miner is allowed to change. And after the fork, it will be the nonce value. Then all should work.
  12. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    Yeah, the way I understood the explanation originally is that the Stratum miner needs to be given a template of the "coinbase tx" plus an offset in it where it is allowed to adjust the extra nonce. In the case of Xaya, the "coinbase tx" is instead the actual Xaya block header, while the "fake block header" that the miner works on is part of the PoW data. That structure apparently works with Stratum, except that there needs to be a place for the "fake extra nonce" in the real Xaya block header - which is where the fork comes in, as it will allow using the "nonce" field in the block header for just that. But perhaps there is another way to do this - as I said, I've never really looked into the "hardcore mining stuff".
  13. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    Interesting ... when I was talking to somer other miners, they said that the Stratum protocol needs to have some field for the "extra nonce" that it is allowed to change and that's not part of the mined PoW block header but the coinbase tx (for Bitcoin) or the "actual" block header (for Xaya). For Neoscrypt you don't really need an extra nonce, but the protocol still requires it - so how did you solve that? Or is my understanding just wrong, as I don't know much about Stratum or mining myself?
  14. domob

    Xaya-Mining-Pool - 1% fee - Stratum

    Great news! Did that work even though the presumable Stratum-incompatibility will only be fixed after the hard fork activation in a few days?
  15. domob

    98% of HUC coins haven't moved

    Nice analysis (keep them coming)! I think it is expected that many HUC holders may not have moved over to Xaya yet or perhaps are no longer in the blockchain space at all (if their HUC were from an early time). But I think that also those who are interested in Xaya do not really have an incentive to move coins immediately - perhaps most of them are just hodling. Personally, I moved one of the outputs I received from the airdrop (for my HUC) into a different wallet and used it to play some TreatFighter during the open beta phase. The other outputs I received are untouched (but imported in my wallet), and will likely stay untouched for a long time. Probably many others will act like that as well.
  16. domob

    Xaya Rich List

    The address you pointed out is not the one for bounties, but the one used to pay the 1.5% advisor coins from the ICO. All of them have now been paid. The bounty address is chi1qzpeqgsgcw7q9hrysa89d5u7z56wgs3sg5aj6an. That one, the company funds address holding 7 million and the one holding 2.4 million coins for remaining presale participants are the only ones left for "official company business" from the top ones.
  17. domob

    Hard-Fork - Update before Block 440,000

    I'm not aware of a distribution graph, but yes, CHI block rewards are halved every four years (4.2 million blocks) just as in Bitcoin.
  18. domob

    Hard-Fork - Update before Block 440,000

    xaya-hash computes the PoW hash of a block header for the two algorithms that Xaya uses. This is mainly used for regression testing and has probably no real use for end users; perhaps some developers might find it useful, too. xaya-tx is a command-line utility that can construct and manipulate raw transactions. It is, roughly speaking, a more light-weight alternative to RPC commands like createrawtransaction that can be used without downloading the blockchain. I've used it myself from time to time, but this is certainly also only useful for developers or advanced users. What other files are you interested in?
  19. domob

    All cryptocurrencies will be mined (total supply)

    Where did you get that statement from? There are a couple of inaccuracies with it. First, every cryptocurrency can have different rules - so you can never say things like "all cryptocurrencies" this or that. Second, taking Bitcoin as example (since it is the most prominent cryptocurrency), then there will be non-zero block rewards far longer than 2033; I don't remember the exact number right now, but the "final halving" will not take place before 2100 for sure. And third, even after that happens, miners will simply get transaction fees (as they already do today) - mind you, last year during the hype, there was already a time when transaction fees for blocks were almost as high as the block rewards!
  20. domob

    Large tx increase

    Just a wild guess, but probably the Treat Fighter competition? Nice graphs!
  21. I spent now some time experimenting with batch requests. I set up a regtest node with 10k blocks, and then sent multiple batch requests (although not in parallel) for all of those 10k blocks each. With this, I do see memory usage increasing (in my setup it roughly doubles to the level before the request) during each request, but it also drops afterwards. I think I saw a slight increase overall, but definitely the majority of the memory gets released when the RPC call is finished. I guess the increase I do see might be due to increased buffer or cache sizes, perhaps. My situation is of course still simpler than what you do - I'm on regtest with empty blocks, only requested 10k blocks instead of 100k, and do not run the requests in parallel. So perhaps that makes the difference. What kind of memory usage are we talking about in your situation, BTW? How much does the daemon use before the requests, during and after? Also, do you see the same happening if you just send one big batch request rather than multiple in parallel? If you have a Github account or are willing to create one, perhaps file an issue against Xaya first so we can debug and discuss this a bit more - even though the issue is likely also present in upstream Bitcoin.
  22. Interesting - I'm not aware of a bug like that. But in any case, that must then be a bug in upstream Bitcoin. I'll take a quick look today to see if I can easily fix it - otherwise I'll let you know so you can open a bug against upstream Bitcoin.
  23. domob

    Xaya Rich List

    Yes, we are aware of this (probably an upstream bug inherited from the Namecoin explorer we use). @RyuMaster Gorskov will fix it at some point, but it is not highest priority.
  24. I'm not a big gamer myself either, but here's my guess (to participate in the fun at least a bit): 17,042
  25. domob

    Xaya Rich List

    The difference you see is probably due to coins left over from the HUC snapshot that were burned. Due to some rounding that was done when the HUC/CHI rate was determined, we needed around 14 CHI less than what was allocated by Andy. I burnt the remaining coins in c90cd16b4caca293b71f75361d61ac35de1e902db020e0cc7729170a4087f266. Also note that in theory everyone else can also burn coins, and miners can choose to get a smaller than allowed block reward - so while I don't think any of that happened (yet), it is perfectly possible to get a smaller actual money supply than what is in theory available.