Jump to content


Dev Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


domob last won the day on June 21

domob had the most liked content!

Community Reputation

132 Excellent


About domob

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That is very strange. As far as I know, xayad should not give you any error of that kind; if anything, then xaya-cli or your JSON-RPC client should. So you run the xayad command, and that error gets printed? What does your debug.log file (in the Xaya data directory) show?
  2. Does the Mac package not contain xaya-cli? @snailbrain - I think it should (if it doesn't already). But yeah, as you said, you can use the wallet console to send commands as well. What command are you trying to send when you get that error?
  3. Yes, these payments are the "fees" for creating characters in Taurion. Those fees go to the team, in order to fund further development - thus they are paid to the premine address (which is a secure, multisig shared address between us).
  4. domob

    HUC delisted

    I still hold some HUC (and plan to keep on holding, of course, as this is a really pioneering project). But if you want to buy some, we could do an OTC deal as well (just message me if you are interested).
  5. Yes exactly, they are modelled after payment channels. However, one key difference is exactly this "proving that your opponent stopped responding". With payment channels, you circumvent this issue by simply allowing anyone to just settle the current state at any time. That is also the approach taken e.g. by Ethersips. I've not yet seen anyone else who actually goes for "complex" games where you can't simply determine an intermediate payout.
  6. What you are talking about is the situation that Alice (actually for a variety of reasons) might just stop responding to Bob (or might refuse to send a next valid move). That's the core issue solved by game channels. Basically, Bob would then post the state of the game on chain, and through that prove that he won (but read the paper if you are interested in the details).
  7. I've also just very recently started working on game channels (finally!). Together with the core framework, we will build a battleships-like game as the tech demo / initial example. For that, we also use hash commitments to ensure provably fair gameplay without the need of any central servers. You can find some preliminary informations about how that game will work exactly in our repository. (This is still heavy under development, though.) In general, hash commitments work very well to do all kinds of things between a known set of players (e.g. a game channel game). For determining random events in a full game world (like disasters in Huntercoin), however, things look a bit different. I've recently written a paper about that as well, using an entirely different approach.
  8. That is a very good question. In some sense, you are right that you have to design games in such a way that it is ok for everyone to have all the information. However, there are still ways to implement hidden information. For instance, using a "commit / reveal" scheme. For instance, you may want to give players the ability to set "traps" on a hidden location on the map that then attack someone who comes close. You can implement that by having players publish a (salted) hash of the location when they set the trap; this ensures the data is "fixed", but the location itself cannot be determined from it. Then if someone gets in range, they can publish the preimage (real location), and it can be verified that it matches indeed the hash they published previously (so they are not claiming a trap to be in a wrong spot). This is of course a very basic design, but you can build more sophisticated game features with this (or similar) concepts as well.
  9. It is, they use the same underlying pubkey hash and just have a differing base58check version. You can use the script in contrib/namecoin/convertAddress.py to do the conversion. Also, contrib/xaya/huc-snapshot contains some data for the snapshot.
  10. So far, I don't know anything about that Godot engine (@RyuMaster Gorskov). But one thing to note is that with Xaya, you typically build the backend and frontend of your game separately. The backend part, which is handling the blockchain and using libxayagame, corresponds to the server of a centralised game. So when people talk about "game engines", then what they typically are up to is the frontend. That, however, can be built in whatever framework you want anyway, and has no need to use libxayagame itself. My (uninformed) guess here is that the situation is different with Enjin, as they don't really have a proper blockchain backend at all, and their integration is mostly about just using blockchain assets in a centralised game / displaying them in the frontend.
  11. Indeed it is. I do not know the reason for this particular event, but we discussed in the team internally and will try to find more miners interested in SHA256-d merged mining. Especially from my point of view, that is a much higher priority than working on the GPU mining aspects.
  12. I'm not aware of any discussion, but yes, it matters. Names in Namecoin are just arrays of bytes. Xaya mostly inherits that, except that it only allows certain byte strings (for instance, they must be valid UTF-8).
  13. Yes, that's a bug in the example (although one in Namecoin). So ideally file an issue on the Namecoin Github (https://github.com/namecoin/namecoin-core).
  14. Great! Do let me / us know if you have any more questions, we're certainly happy to get more people building on Xaya!
  15. For doing an online game, I would write the backend / game-state processor in C++ just as in the "SQLite Hello World" tutorial. You can then run that on your server (but everyone who wants to verify themselves and be "fully decentralised" could run it themselves locally). The main difficulty with doing a game fully online is that you need a wallet in the user's browser, basically the equivalent of MetaMask.
  • 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.