Quote from: CrazyCraig on December 02, 2016, 06:50:30 PM

Quote from: Lanzador on December 02, 2016, 04:59:49 PM

Quote from: CrazyCraig on December 02, 2016, 03:37:44 PM

Quote from: Lanzador on December 02, 2016, 03:10:06 PM

Quote from: VegasCasinoBits on December 02, 2016, 07:31:01 AM

Quote from: alexbilodeau on December 01, 2016, 09:00:36 PM

Quote from: RHavar on December 01, 2016, 05:38:16 AM

Quote from: alexbilodeau on December 01, 2016, 04:19:56 AM

I just read this post, I still don't understand how the app owner can get the user token without malicious code!

The app owner is always given the token. And besides, the app doesn't even need the users token in order to access the money. (It can directly access it itself). Only put what you are willing to trust in an app (as it's clear by the warnings) Grin

Although the important thing to note, is if you put X in an app, the app can steal up to X. But it can never undetectably do so. i.e. It can never rig the bets. But it can bet without you authorizing it to. And it can transfer without you authorizing it to. However, if it does nasty stuff like that, at least you'll know it. (But you'll still lose your money).

What is the reason why an app owner can access the money without even using the player token? I find it very dangerous.

Its like all orther casino sites, when you deposit to a casino site "wallet on MP" to "casino owner" then you build on trust, if you move x bitcoin from you wallet to a orther casino site with own br, then you have the same risk.

Unclear why they need access to the bits though? Given that they're not actually processing the bets, what's the rationale behind letting the app owners access the bits at all? I've tested making my own app on MP and never needed to actually be able to take the bits to get the functionality that I wanted

An app doesn't have control of the bits as you think as they are not physically in possession of the bits. They are not able to transfer any bits without using MoneyPot's API, which in itself, leaves a history trail. If anything malicious were to occur, MoneyPot would know. At anytime, a user could transfer the bits from the app, even if the app were to suddenly disappear.

An app handles the delegation of a users bits through wagers and tips. An app needs these abilities in order to function. With the current setup, an app tells the API how much the user wants to wager. MoneyPot makes sure that the funds are present and handles the wager and 100% of the transaction ledger. MoneyPot itself adds and deducts funds from the users balance.

The warning itself exists as it is theoretically possible for an app owner to act malicious and tip users funds to his or her account or place wagers without the users permission. If these acts shall occur, it is important that the user alert the Moneypot staff immediately so we can investigate the issue.

As a user, it is also your job to ensure the safety of your funds. After you are done wagering, transfer your funds back into your Moneypot wallet, and again, report anything suspicious.

MoneyPot will do its job by continuously vetting apps and making sure that approved apps remain complicit.

Two of the things that we have on the roadmap are automation and an improved token system for confidential apps. Automation will allow us yo have scripted users that test the functionality of approved apps to make sure that they remain properly operational. Think of this as a sort of unit test.

You explained why the wager function is necessary, but not the tip function. I don't understand why the app owners need to have the ability to tip people with other people's bits

The tip function in API v1 is used as a catch all. Developers use it to develop PVP games and other features that the basic API doesnt support. On top of this, the tip feature is used in cases such as Bit-Exo's rain feature. It adds sociableness to games.

For PVP certainly, though does MP even support PVP games? I know BaB and real Poker and Black Jack are off the table so what is it being used for? Also why does a rain feature necessitate access to user funds? The direction of access should be the other way around, if anything it seems