Jump to content
News Ticker


Dev Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by domob

  1. To add to what ty already said:  Yes, the wallet contains a seed, so that future private keys and their addresses can be derived deterministically.  Unlike some other crypto wallets, Bitcoin Core and thus Xaya Core do not easily expose the seed (e.g. in form of a 12-word-sequence), but they have one nevertheless.  Thus someone finding your USB stick can indeed recover also future addresses.

    If you have the USB stick itself encrypted or have a wallet passphrase, then the wallet is safe unless the thief or finder can crack those passwords.  But yeah, if I were you and just to be safe, I would create a new wallet and transfer everything there as ty has recommended.  (And don't forget to make a new backup!)

    • Thanks 2

  2. 4 hours ago, DarkClaw said:

    Is it possible I need to update xaya? Have any new tx types been added?

    No, that should not be the case.  Perhaps someone started using some types of transactions you hadn't implemented before, but we did not include anything new in the core daemon recently.  And it was also not us who started doing something weird recently. :)

    • Thanks 1

  3. Hm, that sounds strange.  Xaya Core should certainly support tracking more than one game, and in your situation, the second move should come with game-block-attach json secondgame.  There's also a regtest that verifies exactly this, IIRC.  So it "should" work.  If it doesn't, then please open an issue on our Github.

  4. As with Bitcoin and most other blockchains, miners can freely choose what to include and not to include in their blocks.  So in theory, someone could send transactions without any CHI attached and get the mined, e.g. by paying the miners out-of-band (maybe with BTC or fiat), or by including some game-coin transaction to them instead of CHI.  But I think there are strong reasons why that is not going to happen any time soon (nor will it happen with Ethereum):

    • A game would need to be really popular for that to happen, because the miners themselves need to run the GSP for it and also be interested enough in it to actually accept payment in the game coin directly.  While not impossible, that's certainly extra effort for them (much more than simply running Xaya Core on their system).
    • Paying in game coins is likely a lot less efficient than paying transaction fees in CHI, since the latter is "better integrated" with the core blockchain and transaction structure.  So accepting fees in game coins will likely increase transaction size and thus reduce the number of fee-paying transactions that miners could get into their block.
    • Not just miners matter, but also relaying nodes.  So unless either a large fraction of the network runs a modified client that accepts game coins for fees or users submit their transactions directly to miners, transactions won't even make it to miners if they do not pay CHI.  For the first case, we would again need a hugely popular game as well as most people messing around with their Xaya Core installation, which seems even more unlikely than a miner doing it.  For the second case, people also would need to spend a non-trivial amount of effort to figure out who the miners are that accept their game coins and how to submit moves to them directly.
    • Even if some miners accept fees in game coins and you would eventually get your move confirmed, most likely it will take longer than if you paid CHI (unless 100% of miners accept the game coin, which seems impossible in practice).  So you are at a disadvantage.

    With all those disadvantages, I simply do not see why people and miners would bother.  If they have / earn game coins and want to cover fees with them, they can instead just sell them for CHI anyway and then use CHI.

    All those technical aspects aside, it seems that your main concern here is about the potential for CHI to increase in value due to demand.  To be honest, I think that for that topic, usage of game coins for transaction fees is a very theoretical thought for now.  99.999% of CHI demand and potential price increase is likely just speculation - and if games are doing well, then that is a good first step independently of how those games actually use CHI.

    • Like 2

  5. I think this question mixes up a couple of things.  First, for this question, it does not matter whether games run in game channels or not.  Second, you always need CHI in order to pay transaction fees, register accounts and do other things on the core blockchain.

    The actual use of currency in a game is a bit more nuanced.  The main thing to keep in mind here is that the Xaya model does not allow game logic to affect the movement of CHI (the reason being that this in turn allows vastly better scalability to complex games than e.g. Ethereum).  This means that games can very well use CHI in the sense that they react to voluntary movement of CHI; an example is Treatfighter, where you can by crystals for CHI - but in principle the whole game would work without crystals at all, and with payments being done directly in CHI.

    Where this does not work is things like betting on the outcome of a game or for instance SME, because there the result of some game computation may require that e.g. the loser sends some money to the winner, or the club pays for player wages; and this has to be done even if the user does not explicitly sign a transaction moving CHI.  In that cases, you need to use an in-game currency instead.

    An exchange could certainly list an in-game currency (e.g. SME coins) directly if they wish, but you will still always need CHI to pay for the core blockchain features (e.g. tx fees).  Also, it will be possible to trade game assets in a trustless and decentralised way against CHI, so that there will be a natural tendency to have CHI as "base currency" for all game-asset markets on Xaya.

  6. The initial version will be for desktop only.  But we are definitely thinking about Android support, and already have most bits and pieces ready to support mobile gameplay as well - it just needs to be put together and polished.  So Android / mobile support will definitely come at a not-so-distant time in the future as well.

  7. 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?

  8. 13 hours ago, DarkClaw said:

    Well, I've still got some buy orders down there. Lets see if they get hit.

    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).

  9. 10 hours ago, Christian Pichler said:

    Game channels are a good solution to implement blockchain games- they seem to be a similar concept as the payment channels for the lightening network in bitcoin.

    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.

  10. 3 hours ago, Christian Pichler said:

    I just read your article about battleships on github... isn't there still the possibility that if Bob wins the game (and should be rewarded with Chi from Alice), then Alice could prevent the  message "Alice lost" from being sent to the xaya network from her local computer... Bob will of course send the message "I won" to the blockchain... how do you solve this dispute then? Is this done by the xaya main chain?

    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).

    • Like 1

  11. 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.

    • Like 1

  12. 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.

    • Like 1

  13. 10 hours ago, DarkClaw said:

    Maybe it is possible to get the HUC address from the CHI address? I haven't tried that but it could be interesting.

    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.

    • Thanks 1

  14. 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.

  15. 11 hours ago, DarkClaw said:

    No one else cares about this? It seems like a quite notable event.

    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.

    • Like 1
    • Thanks 2

  16. 9 hours ago, Ryan said:

    If you're doing it online, I'd ask Daniel about what sort of architecture would be best.

    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.

  17. It is nice to hear you want to try your hands on a Xaya game - that is highly appreciated!  Be sure to first read our tutorials and other documentation, for instance "SQLite Hello World" one.  And don't hesitate to ask more questions as you go along!  Also, you can take a look at our xid repository, which implements a simple but full-fledged game.

    I'm not exactly sure what you mean with your server/client question.  You do not need any servers at all, as every node in the network (with the full XAYA blockchain) can compute the game state for themselves as well as handle all reorgs.  But you may want to design your game locally in a client/server fashion, where the game backend provides a local server (built with libxayagame) and the frontend / UI talks to it.

    Calculating the damage and doing all other things will be done in your game logic's "update callback" - that is explained in the tutorials.

  • 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.