[Design] HathorDice: Discord and Telegram Bot

[jansegre]

Introduction

Inspired by the original SatoshiDice, HathorDice is a simple betting game. The basic idea is really simple, you choose how much you want to bet and optionally a cap (which defines the odds and the reward), a die is rolled and if it is lower than the cap you win the reward, otherwise you lose the amount bet.

Although it might be possible to implement a "trustless" bet (using opcode scripts, and shared (from both betting parties) dice rolls, or a trusted third party random number source) this design proposes a simpler MVP where the house keeps custody of the tokens (that is, the user has an "account" or "second wallet" in control of the HathorDice service, to be used for bets. This isn't ideal and opens up a lot of trust concerns, but this makes the implementation and usability easy enough to get something off the ground working.

The Bot (frontend)

Initially there will be 6 commands the bot will accept, which can be called from a DM or from a public channel:

Commands that work everywhere:

• help: basic explanation of how the bot works and list every command and where they can be used;
• odds: the bot will respond with a list of valid reward multiplier, odds, and max bet amount for each multiplier.

Commands that only work on "private conversations" or "direct messages":

• deposit: the bot will respond with the address the user can use to deposit funds to;
• withdraw [amount] [address]: the bot will withdraw the requested amount to the requested address from the internal user wallet;
• balance: the bot will respond with the balance on the internal user wallet, which is the max amount the user can bet.

Commands that only work on public channels:

• bet [multiplier] [amount]: effectively makes a bet with funds from the users wallet, the bet is either invalid (bad multiplier, out of bounds amount, not enough funds, ...), losing (dice rolled higher than the cut, pooled amount is transferred to the bot) or winning (dice rolled lower or equal the cut, pooled amount is transferred to the users balance).

Communication with the bot must be made through a supported frontend. Such as the Telegram frontend, Discord frontend, CLI frontend (for develpoment), or any other implemented in the future.

User uniqueness and authentication is delegated to the frontend, there is no cross-frontend account (your balance using Telegram is isolated from your balance using Discord).

Each frontend might have a specific convention for signaling a command, like !help or /help (which will also format the command list accordingly).

The Service (backend)

It is possible to design a modular and scalable architecture. But this comes with an increasing cost in maintenance and development. It is very likely that we won't have an explosive growth in usage so quick that a simpler solution wouldn't handle it. For that this designs proposes a simple monolithic service that can be left running on a docker container. The deployment strategy and specifics is left open.

The monolithic service shall implement a module to handle communication for each frontend and one for interacting with the wallets. Additionally, it will need a database for storing logs, user accounts, and eventually other data. Although this needn't be set in stone MongoDB is recommended for its flexibility.

It would look something like this:

    Telegram API              Discord API
          ^                        ^
          |                        |
 +--------------------------------------------+
 |  Telegram Frontend   |  Discord Frontend   |
 +--------------------------------------------+   Monolithic Service
 | Database Abstraction |  Wallets/Transfers  |
 +--------------------------------------------+
          |                        |
          v                        v
       MongoDB                 Hathor API

Because hathor-wallet-lib is a node.js library, this would imply the whole monolith would be a node.js app. There are already good libs for each of these modules (Telegram, Discord, MongoDB), so this shouldn't be a problem.

Internal wallets

The bot needs a wallet to take payouts from. For a simpler design we can use a single set of words (a "master seed") for seeding this wallet and the user wallets.

Each platform (at least Telegram and Discord) offers a unique id per user, which would be user for generating the xpriv of the internal user wallet using a convention of ":" as the password on top of the master seed.

Limits and odds

Giving slight odds advantage for the user could be a way to hype the usage of the bot. But this can also be a way to down the funds really fast.

These are the limits we have to consider:

• max betting amounts
• max betting rate
• minimum fund amount to allow operations (because atomically syncing the current funds with payouts and new bets, we should consider a minimum amount to allow any bets to take place instead of only checking if there is enough funds to payout for a single bet)

Security

We shouldn't store any xpriv or seed or any information that allows reconstructing any xpriv without the need for the master seed. Every xpriv should only exist in memory, and even then we would have to worry about exploits that would leak these from memory. To mitigate this losses

Randomness

Since the bot has custody of the user's wallet, the source of randomness may be the least of the "fairness" concern. If this is a concern we could use https://www.random.org/ as a source of randomness, which would most certainly be a neutral third-party.

Nuances

• Disclaimers: legal disclaimers, "betting recommendations" (addictive, don't bet more than you can lose, etc)
• Command aliases (Discord for instance seems to encourage bots to use /start command, which we could alias to /help)

[obiyankenobi]

Design looks good to me.

As for the /start command, I was wondering if it should be the first command used by the user to "initialize" his wallet. We could then fund this wallet with some HTR so he can play. The same could be done the first time a user requests an address, but using /start might be more intuitive.

[pedroferreira1]

It's good to me also, just some considerations to be discussed, in my opinion.

About the /start I agree, it's what I've seen in the bot I used. I typed /start in a random channel and a private conversation with the bot started with my wallet info.

• I still don't know if we should allow the bet command to be sent in any public channels. If we do this, I think we need to keep the result private for the user (so we don't flood a public channel) but I like a channel only for betting where all results are public. Like Result: 2! pedroferreira has just won 0,03 HTR, I think it could be good to attract more people to bet.
• The bot will have the custody for each user's wallet but what about the 'house wallet'? If the user wins, which wallet creates the transaction? And how is the custody of those tokens?
• I haven't put much thought about the backend but I think we could discuss having it in lambda functions. I believe bots are one of the cases where it fits perfectly in serverless solution.

[obiyankenobi]

I agree that we should restrict bot commands to a specific channel, at least in Discord. It's easy to create one in our server. And we should definitely post the bet results publicly.

On Telegram, I'm not so sure about a separate group for bets. It'd only be visible if the user actively enters it, so most people would probably not find it. That's a bit against our idea that the bots should increase public engagement. We might start in our main group and can create a separate one if it becomes too much "spam".

[msbrogli]

I agree with previous comments. I'm still wondering what verification mechanism will be used by the user to check that our bot is following the rules.

Even though I like the idea of using random.org, I don't feel really comfortable using a third-party app. We will have to monitor their website and always double check we are not being throttled there. I agree it is a critical part of the app, but I think we can use any safe random number generator for now.

[msbrogli]

I talked about giving users an initial small credit so they can play before depositing funds. Are we going to do it? Maybe we should include it as optional in the design.

[obiyankenobi]

I talked about giving users an initial small credit so they can play before depositing funds. Are we going to do it? Maybe we should include it as optional in the design.

I think we should. Maybe it's good to add a cap. For example, let's have 1000 HTR total for this and give 5 HTR for people to use. This way, only the first 200 users will get this credit. We can then decide if we want to increase this limit.

[pedroferreira1]

This initial credit will have a wallet as origin. And what about when the user loses or wins, which wallet will give the tokens to the user and which will receive the tokens? The same?

[obiyankenobi]

I think we should have separate wallets for that.

[msbrogli]

But we should prevent users from just withdrawing their initial credit, right? I mean without betting.

[obiyankenobi]

Yeah, that would be ideal. We can check in the withdraw command if that user ever placed a bet.

[jansegre]

I think the initial credit needs a bit more specification. I see these paths:

1. A base credit that can never be withdrawn (effectively like allowing negative balance to some degree for betting but not for withdrawing), scenario:
   • Start with 10 HTR (10 base + 0 won)
   • Bet 5 HTR and win 5 HTR, total balance is 15 HTR (10 base + 5 won), 5 HTR can be withdrawn
2. A credit that is consumed when betting, but not refilled when winning, scenario:
   • Start with 10 HTR (10 credit + 0 regular)
   • Bet 5 HTR and win 5 HTR, total balance is 15 HTR (5 credit + 10 regular), 10 HTR can be withdrawn
3. A credit that can be withdrawn after any bet is placed, scenario:
   • Start with 10 HTR (locked)
   • Bet 5 HTR and win 5 HTR, total balance is 15 HTR (unlocked), 15 HTR can be withdrawn
4. Maybe there is another way that makes sense

Besides the mechanics we'll have to decide on the initial balance, but since this is so much easier to tweak, I think the mechanics is much more relevant right now.

[obiyankenobi]

Your first suggestions seems to be the simplest for me. If each user always starts with 10 HTR, they should only be able to withdraw the difference.

• if balance is 11 HTR, can withdraw 1 HTR;
• if balance is 100 HTR, can withdraw 90 HTR;
• if balance is 7 HTR, can't withdraw anything;

[pedroferreira1]

Yes, I agree the first suggestion is best.

[jansegre]

The mechanism should try to:

• be easy to explain and understand
• be fair
• incentivize playing with the bot (instead of just air dropping HTRs for no use, although something like a HathorFaucet could be interesting I don't think it is the scope of HathorDice)

I consider all fairly equal in fairness, but 1. is the easiest to explain and also gives the best incentive to play (with 2 and 3 you can "unlock" the credit fast and just withdraw it without playing).

But to expand on 1., there is also how it would interact with deposits. I'd say there is two good ways we could go about it (consider balance = base + rest):

1. base is fixed, meaning only the rest can vary, and be negative (it doesn't mean it has to be implemented this way), scenario:
   • Start with: balance = 10 HTR (0 withdrawable)
   • Bet 5 HTR and lose: balance = 5 HTR (10 - 5), 0 withdrawable
   • Deposit 10 HTR: balance = 15 HTR (10 + 5), 5 withdrawable (it almost feels like 5 HTRs are lost again) This approach is:
   • easy to explain
   • fair
   • but disincentivizes playing once you go below the base balance
2. base can vary, meaning that deposits will lower the base such that the whole deposited amount can always be withdrawn back:
   • Start with: balance = 10 HTR (0 withdrawable)
   • Bet 5 HTR and lose: balance = 5 HTR (10 - 5), 0 withdrawable
   • Deposit 10 HTR: balance = 15 HTR (5 + 10), 10 withdrawable This approach is:
   • hard to explain (maybe we can omit the explanation?)
   • still fair (maybe fairer?)
   • incentivizes play, since after testing and loosing the player can effectively "start fresh" by depositing
3. or maybe topple the balance to compensate for deposits?
   • Start with: balance = 10 HTR (0 withdrawable)
   • Bet 5 HTR and lose: balance = 5 HTR (10 - 5), 0 withdrawable
   • Deposit 10 HTR: balance = 20 HTR (5 + 10), 10 withdrawable (5 HTR "on the house", limited to the base amount, or the minimum to make all the deposit withdrawable) This is:
   • still hard to explain
   • fair
   • incentivies play even more? this is maybe equivalent to skewing the odds in favor of the player

What do you think?

[obiyankenobi]

I agree with your point about on scenario 1, that it "disincentivizes playing once you go below the base balance".

I'd say if we agree that the initial value is very small, we can go with your original proposal 3. It's probably the simplest one to explain. Users might abuse it by creating several Discord users to collect HTR, but I'm not sure that will actually happen. And we should have a cap on the amount of HTR we'll distribute this way.

[pedroferreira1]

I was thinking about the other uses for this bot (it will be the same bot for the tips actions). If we go with solution 1 (you can't withdraw the initial 10 HTR), I believe the user should be able to give tips with those 10 HTR, so he could just 'tip' his other account and get the HTR for himself.

Thinking about this and what you said about solution 1, maybe we should just give the user the tokens. We just need to control this (maybe in the ops review) to check that nobody is creating discord accounts to get them (we can probably allow the user to start the bot conversation on some conditions only, e.g. having the discord account for more than a month).

[jansegre]

If we go with the option which has the "least worst" characteristics, the simple "bet once to unlock initial funds" seems to win:

• it's really easy to explain
• it's fair (to the user)
• it incentivizes play (somewhat, the user could just be interested in some free HTRs and make a bet for that purpose only)

So far I'm more inclined to that option.

[obiyankenobi]

I'm good with that too. Given that we probably won't put it live now, I'd say we don't need to debate this much more.

[pedroferreira1]

Yes, I agree. It's good

[msbrogli]

Ok. I agree that "bet once to unlock initial funds" is good for now. But, for a production ready version, I think it is not good because people can just make a 0.01 HTR bet and unlock the tokens.