Slotto

From ThisBlueWiki

Slotto (likely not the real brand) - vending machine which the user pays a nominal sum ($5) which then issues instant cash and consolation prize payments (if possible) or cryptographically verifiable tickets for payment (if necessary) to players.

Game theory would set the expected ticket value to something like $3 paid out for every $5 paid in. Payouts would be split between Slotto and the owner of the actual vending machine (box owner) to prevent the nightmare of Slotto having to rent spaces for the boxes outside shopping centers -- just sell the boxes for a modest sum with a script that gives the box owner a login and password to the external management site where they can go to request payment (via secure tickets, or the site e-mailing a payment script to dispatch their earnings). The boxes would be yes copy, no modify, no transfer.

The primary goal is to get these boxes on every corner in shopping centers, stores, and social areas in order to make money. The boxes should be low-primitive and have a very easy interface, giving out note cards with instructions in English, Spanish, French, Italian, Portuguese and German. Play prices should stay low to accommodate the large number of low-income people inhabiting the world.

The secondary goal is to raise awareness of the chosen brand name for future endeavors such as a purely ticket-based game with payouts in the $50,000 plus range.

Challenges

Vending Machines

This will be an exercise in scripting and interface design that is fairly advanced, even for small/simple machines, but is not insurmountable. The biggest issue is that I believe an auto-update for the scripts in the machines will be very necessary.

Security Considerations

In any game where money is involved (real or virtual), people are going to try to cheat the system. If the business gets lucrative, people will be very interested in coming up with attacks to claim money they have no legitimate claim to. The system, to some degree, is going to have to be backed by cryptography in order to verify payouts -- at the very least to box owners if not to players. Since implementing public-key cryptography in the scripting language may be prohibitive (in terms of time and complexity), this discussion will center around writing the scripts to use XML-RPC and an external web-based infrastructure. Some level of crypto does already exist in the languagage, including MD5, weak RSA capabilities (too slow to be practical for time-conscious operations) and the promising XTEA cipher.

The challenge, then, is to write scripted objects in-world which use a minimum of resources but which can securely authenticate with an external authority in charge of payments.

Play and Collection

Glossary:

slotto owner 

The owner of the entire game

box owner 

The owner of an individual vending machine.

server 

An external server which handles record keeping and is authoritative for payments.

Ticketless

Play

See here for the recipe using RSA -- currently too slow to implement and not secure at a key length of 31 bits. This method is written to use a strong symmetric cipher, but it lacks the digital signature capability of the RSA method.

See here for the recipe using outbound XML-RPC, which is currently disabled.

1. Vending machine takes money and calculates the user's random number.
2. (Crypto) Vending machine contacts external server to verify winnings using an HTTP request.
   • Request format follows. All elements are strong-ciphered and URL escaped. The tuple (player ID, nonce n₁) is used to deny replay attacks. Also, any tickets with a datestamp older than some fairly short period will be denied. After this period elapses, the anti-replay tuples can be expired from the database.
     1. Machine ID
     2. Player ID (name or UUID?)
     3. Player ticket random int
     4. Nonce n₁
     5. Datestamp
     6. MD5 hash of all preceding message components
3. Server responds with win string for the machine to shout, etc.
4. (Feasible?) (Crypto?) Server e-mails master payment script and directs payment, if any, to the player.

Collection

1. The box owner visits a web site and enters his vending machine ID, and selects to receive payment.
   • Box owners should be able to group machines under a login and password and select payment for all.
2. (Feasible?) (Crypto?) The server directs aggregate payout to be sent to the box owner in-world.

Profitability

These napkin calculations don't factor in the income from selling machines -- priced to move at L$250 each, each machine would net just about US$1.

Less than 2750 transactions per day

Assuming costs of about US$35 (~L$10,000) per month for in-world rent for sales space and $30 per month for shared hosting from a reliable provider such as Pair Networks, at L$1 profit per transaction, 17,875 transactions per month (596 per day) are required to break even. This breaks even with just 1 transaction every 2.4 minutes worldwide.

2750 transactions per day and up

Assuming costs of US$250 per month for a sim (US$200) and a virtual private server (US$50) to handle transactions and run the web site, at L$1 profit per transaction, 68,750 transactions per month (2,750 per day) are required to break even. This breaks even with just 1 transaction every 30 seconds worldwide, and with the cost of renting a dedicated VPS and owning an entire sim.

Marketing

To raise brand awareness, price machines to move, make them copyable by owner (to encourage liberal placement), and use an "every play wins!" approach by giving away free items to players who don't win money.

As income and brand recognition increases:

• Branded machines. Store owners can purchase a copyable machine for a tidy sum (say $2,500) which is stocked with items from their store as prizes, and they set their ticket price -- with slotto still taking 20%.
• AvLotto. Slotto will commission designers to make or sell designs for high-quality shapes, clothing, hairstyles and accessories. Men's and women's AvLotto machines would give these items as prizes. "Losers" would get very basic items, winners would get high-end stuff. Ticket price would be higher, $10, with slotto taking 20%. This has HUGE potential given the volume of customization business and the compelling nature of customizing.

Questions

• Are scripts visible to owners of no-mod objects? No!
• Can scripted objects pay a user from some kind of account? With llGiveMoney, they can pay from the script owner.
• Can scripts/scripted objects execute actions, such as payment, to a user when receiving e-mail from the outside world?
  • Can scripts run continuously and autonomously (to implement a polling payment entity that retrieves data via XML-RPC every 30 seconds or so)?

Links

• Slow 31-bit RSA function - LSLWiki entry on broken llModPow
• http://wiki.secondlife.com/wiki/XTEA_Strong_Encryption_Implementation
• llXorBase64StringsCorrect in PHP - should be useful if you're using llXorBase64StringsCorrect to do cryptography work in LSL2 and posting it out to the web via llHTTPRequest