Problems Using the RCL as a Real Cash Economy Game Platform

Technical questions about the Ripple API, the protocol, etc.

Problems Using the RCL as a Real Cash Economy Game Platform

Postby twarden » Sun Nov 25, 2018 4:10 pm

This is an incomplete list of the problems when it comes to utilizing the Ripple Consensus Ledger as a platform to host a Real Cash Economy Game.

The Problem of Ripple IOU Divisibility and Ripple Gateways

twarden wrote:In the mind set of a precious metals company wishing to operate as a Ripple Gateway, some Ripple IOUs they issue would have a problem that they are divisible.

For example, if I were to wish to issue the new 1oz Liliana Silver "coin," then I would want to ensure that when I post an offer-create to an order-book, say offering it for XRP for its fair market price as a numismatic coin with a known serial number to the customer (lower certificate numbers are seen as more valuable), then there must be some reliable mechanism for the issuer to state that specified Currency Codes may only be fully, partially, or non-divisible and for these settings to be known by the Ripple account holder who is considering extending trust for these unique asset classes issued over the RCL.

The implementation of this feature will provide a solution to the potential problem of an issuance no longer being viably redeemed as a bad actor has purchased a very small amount of the IOU but a large enough amount to then attempt to create a 'secondary market' by reselling these specially issued Ripple IOUs for profit derived from the intended market audience.

The RCL does not have a reliable mechanism to ensure that when game assets are posted to order-books with an OfferCreate transaction they do not sell the IOU(s) for less than 1 complete unit of account for the issued game asset IOU currency code. This makes it impossible to offer the following items:

-Equipment (I.E. ammunition cannot be "half a bullet/arrow," you would be useless with half of a sword in combat, and wearing half a piece of plate-mail won't do you any good as far as defense)
--The proof-of-concept RCEG I am designing is being made with play-to-pay and free-to-play participation experiences. As a part of the pay-to-play model, certain Game Bundles which may be purchased will offer consumable items used within certain aspects of game-play. While it may be somewhat feasible to imagine "redeeming half of a burnt torch" it is not feasible to redeem "half of a land area deed" nor is it possible to "redeem half of a "fee waiver/coupon" which are item(s) unique to these Bundles.
-Vehicles (half of a car/horse?)

Proposal: SetFreezeTransferRate #2768

There is currently a cryptographic mechanism for an Issuing Account to state to the Ripple Consensus Ledger/Ripple Network that its issuances will charge you fees when creating Payments to Ripple Accounts which are not the Issuer and for creating OfferCreate transactions using the Gateway's IOUs. There is currently no mechanism for Ripple Gateways to cryptographically promise that they cannot re-set their TransferRate at anytime of the operator's or operators' choosing. It has been suggested that such a feature to set a Freeze flag for the TransferRate once it is set (if unset/0 then it may not be changed). It has also been suggested that such a Freeze flag for the TransferRate should not be so 'draconian' and that if the TransferRate has been set to say 3% then the Ripple Gateway operator or operators set this flag then they may not increase this value above the figure when the SetFreezeTransferRate transaction was successfully validated in a last closed ledger. I although the second suggestion will allow an Issuer to set the TransferRate to 0 and set this flag to ensure no further changes, I still prefer the feature of Freeze to mean absolutely no more changes to the Object in question once set just as NoFreeze currently operates.

Proposal: SetFreezeTickSize #2769

As the Issuing account of a RCEG must be consistent with the value of their IOUs when an OfferCreate is sent to the RCL, there must be a reliable cryptographic mechanism to promise to the speculators/investors & players of the game that their trades will have a known granularity when setting a price for exchanges. As the concept of my RCEG is based on a real-world value tie-in of physical Silver, there must be a reliable mechanism for me to promise to users of this and all other game assets that the most significant digit for OfferCreates is the 8th decimal place as that is the most significant digit when it comes to trading precious metals. If I could cryptographically sign a promise that this cannot change then it would only add trust, stability, and reliable to the Issuer.

Proposal: Allow Government Entities to announce ownership of issuing account #2771

whotooktwarden wrote:This is probably far out into the future and probably already on Ripple Inc's radar in some form already but I just have to be the annoying one and write this before someone else takes the opportunity away from me.

I propose that the rippled team of developers discuss internally with the Ripple Inc Legal/Regulation teams for their plans for the future if a Government Entity were to wish to cryptographically sign a promise that they are acting with some kind of authority provided through a Government. I believe that they may wish to set an account flag. I suggest that this action consume a large portion of the account's XRP and that the flag can not be unset unless some kind of condition is set/met that requires the flag to no longer be active I.E. by a specified ledger, collapse, or restructuring of Government.

That is all. EDIT: My exact reasons why this issue and the previous two I have raised are necessary for my use case are a separate discussion best not to be raised on github available on the official Ripple forums.

nbougalis wrote:I don't think this is an appropriate feature for XRP Ledger and I am very much opposed to it.

First, it's unclear how anyone could verify that such a transaction was performed by someone "acting with some kind of authority provided through a Government."

Second, if a government entity wants to announce "ownership" of an account, all they need to do is demonstrate the ability to sign a message with the account's secret key. No further on-ledger mechanism is necessary. For example, if Robonia wanted to claim an account, Robonia's government could pass legislation requiring that a transaction with sequence number 1 and the following memo be signed with the secret key associated with the rRobonia account and submitted to the network for processing:

The account rRobonia is the official account of the Grand Duchy of Robonia. This message is being submitted as a memo in a duly signed transaction with sequence number 1 on said account, in accordance with public law 123.456/3004, passed by the Robonian Assembly.

Note that this applies to any entity really. Substitute ACME Corporation for "Robonia", "Board of Directors" for "Robonian Assembly" and make other relevant tweaks.

Lastly, the Ledger has no way of knowing when many of the kinds of conditions you suggest should be met would be met to unset the flags; in fact, for several of them, it may not be possible to actually reach consensus about whether such an incident has in fact taken place even if you were to delegate the task to human operators.

I believe that this issue should be closed. As is, it's non-actionable and I intend to close it in 24 hours. If you are interested in discussing this issue further, feel free to do this on another forum.

whotooktwarden wrote:I knew that there would be obvious problems that the ledger would have no way of dealing with really (collapse/restructuring of Government) which is why I wanted to see what could potentially be done to solve those problems.

Your idea of legislation plus a memo added to the ledger would satisfy most people that an issuer is acting with some kind of authority. Perhaps adding a line to the memo stating that if another memo is not posted by a certain date/ledger sequence then to not trust that the account is operating with the express authority of the Government/Organization in question would in some way be able to satisfy the collapse/restructuring scenarios.

Just thinking about the future an I will discuss the topic on the forums in the future, this can be closed if no one else has anything they would like to contribute.

This is a closed issue. However, this is still of very much interest to me, therefore I went ahead and registered the domain name to begin to build a product I will announce soon-ish (when it is ready, it is done). I have also taken the initiative of contacting a member of the Independent Senators Group in Ontario who has a background in Canadian Law in securities. I promised over Twitter that if I don't get a response within 10 business days (about a week remains) then I will share the email I sent on the official Ripple forums so that this effort of mine can possibly turn into a community effort by making this contact with this specific Senator into an open-letter to the Canadian Senate.
All I will say for now is that Ripple Inc has already been notified and that this project is a prerequisite to building a Real Cash Economy Game and that this web site will act in a similar manner as the "International Ripple Business Association" (IRBA) once did with creating a set of community best business practises.

Note: I was thinking of hyper-linking to the current iteration of the IRBA website but I noticed that they're still listing Gateways with dead, un-backed IOUs...I sort of want to know what's going on thar.

The Troubles of Single Delivery for Ripple Account Activation

On 3/11/2016 at 11:17 PM, Hodor said:
In this scenario, I assume we are playing the role of a gateway, correct?

So, if that's the case, then the gateway will fund each wallet with a small, minimum amount of xrp. Were I the gateway, I would have an overall account for an individual, that must be funded prior to my creation of their pre-funded Ripple wallet. Basically, I am then covering my out-of-pocket cost of pre-funding their wallet.

Or are you thinking of creating an automated service that will open an API up and prefund wallets with a minimum of XRP to try to get increased adoption of XRP? In that case, abuse is far more difficult to curtail.

Twarden wrote:I am thinking of this in both terms as a gateway and someone who would like to create a closed loop system that uses ripple accounts to manage transactions without the user needing to know or understand what a ripple address is. The processes would just fire upon activation of a new wallet an is mostly for experimentation but also for some practical use cases. One example is to create a new ripple account, activate it, and perform an update settings transaction based upon settings I require for the use case or set by a user via collected form data. As a gateway I would like to create a new account for a user, activate it, and set trust-lines for the assets I accept at a conservative default limit to avoid any trouble with deposits if a user has not already created a trust-line.

On 3/11/2016 at 11:25 PM, nikb said:
It's really hard to anser this question. You don't provide any sort of guidelines about what rates of type I and type II errors are acceptable, or any limits on the platform toolset (will this run in the browser? dedicated software? can we assume access to out-of-band communications? etc).

Frankly, if you're looking to do this using a "fingerprint" of a user's system (e.g. hash of the serial number of various components) then you're almost certainly fighting a losing battle. You're basically talking about creating something equivalent to a software activation service, like the one Microsoft uses. It's not an easy problem to solve, especially when your code needs to run on machines that you don't trust and can be assumed to be hostile.

Depending on how long you want to make the user wait and your penchant for risk, you may be able to much such a system work if you require users to download and run a piece of software that gathers the information you want, sends it to you and then begins calcuating some unique code based on that information but does so very slowly - think on the order of hours. If you require the user to remain in constant contact with your server while the calculation takes place, you can make it cost a lot of time (and potentially money, depending on how many machines an attacker chooses to wield). Probably overkill and neither bulletproof nor that easy to implement but it's something.

Another option, would be to use a combination of a CAPTCHA (to reduce the likelihood of automated signups) coupled with SMS activation; once the user registers, simply send a message with a unique code to their cell and do not allow a number to be reused. Again, not bulletproof, but the barrier to entry is probably just high enough for now that it, when coupled with limits on how many SMS messages you send per minute, would prevent outright abuse and allow time for suspicious patterns to be investigated.

Twarden wrote:I would like to implement a system like this in browser primarily using the ripple library, java-script, and perhaps where needed to run rippled api commands a combination of PHP and Ruby. I knew that what I was describing would be incredibly complex an I had imagined a situation in which you described where the user would be required to run a downloadable client to sign up to the service but I came to the same conclusions you mentioned (not to mention the time an costs to build an maintain such a system).

I will take you suggestion under advisement to use a combination of SMS verification with a conservative maximum acceptance rate per minute, CAPTCHAs, and carefully monitor for abuse.

As this Ripple-based Real Cash Economy Game will require you to own your own secret key to your account, this becomes mostly irrelevant in the context of this thread's content. However, there is to be a giveaway component to this game upon release which will in some ways act as a method of "universal basic income" to all of those Ripple users who are able to sign-up for a free-to-play account then receive the giveaway package.

I would really, really like to see some form of cryptographic feature in the RCL that will allow for the following:

-assess if a Ripple account was activated by a certain timestamp and/or ledger sequence number, if not, then fail
-assess if the Ripple account has been issued the unique identifier for a 'promotional payment transaction,' if the user has claimed this promo's ID code already, then the transaction fails
-If the Ripple account passes these two checks then a payment transaction is proceeds processing with the IOUs delivered. If the user has insufficient trust-lines for the transaction to take place then it will not record the user as 'redeeming the promo ID' and fails with a tec code. However, if the user has sufficient trust-lines for the payment to become validated, then the promotion is unavailable to this user if they attempt to initiate the 'promotional payment transaction' using the Ripple Gateway's website which will offer this automated feature.

The above will require the feature request Proposal: multi-transaction #2534 to be implemented first.

Please discuss these topics as it relates to using the Ripple Consensus Ledger/XRP Ledger as a strategy to offer a Real Cash Economy Game and Universal Basic Income platform.

Don't worry! I'm pretty sure that I got this under control, the last crazy visionary was was far too insane, but I struck the correct balance.
BCT Thread

I am not affiliated with Ripple Labs.
User avatar
Posts: 765
Joined: Fri Jul 04, 2014 11:21 pm
Location: Ontario, Canada

Return to Developers

Who is online

Users browsing this forum: No registered users and 3 guests