monicanagent / cypherpoker

An open source implementation of peer to peer cryptographic poker ("Mental Poker")

CypherPoker

Note: Further development on the ActionScript CypherPoker project has been halted. Please visit the new CypherPoker.JS GitHub repository for updates.

CypherPoker is an open source implementation of peer to peer cryptographic poker, or Mental Poker, written in Adobe ActionScript 3 (for Flash and AIR), and built using open source software and tools.

It is the culmination of decades' worth of research and analysis by some of the best minds in cryptography; Ron Rivest, Leonard Adleman, Adi Shamir, Don Coppersmith, Shafi Goldwasser, and Silvio Micali to name only a few.

The full game, as hinted at in the 1979 Mental Poker paper, was not practical on the computer hardware of the time. Although capabilities have since greatly increased, to date the most complete implementation has been Heiko Stamer's LibTCMG library and source code for the game Skat. Unfortunately, the simple game and Stamer's library have been dormant for years. Only a handful of other attempts at Mental Poker presently exist in nascent stages and as nothing more than proofs-of-concept.

Meanwhile there have been many interesting and exciting discussions about how software of this nature could be used, extended, and adapted. However, these have all been mostly theoretical in the absence of a practical implementation. With CypherPoker I intend to provide this implementation and refresh the dialogue with new possibilities.

---

To get started with the CypherPoker source code please visit the wiki: https://github.com/monicanagent/cypherpoker/wiki

*Note: The trunk CypherPoker respository should be considered the most unstable, in-development copy. For stable development snapshots see branches (https://github.com/monicanagent/cypherpoker/branches).

Familiarity with ActionScript 3 or its weakly-typed cousin JavaScript are not a requirement in order to compile the software but are useful when desiring to make changes to the code.

Where possible, third-party or other external libraries have been included. You are encouraged to check the official distributions for these libraries from time to time to ensure that you have the most appropriate version(s) available.

cypherpoker's Issues

Integration - ActionScript: Automate Ethereum connectivity

Using game messaging to exchange initial information, automate Ethereum client connectivity between active enodes (for example, admin.addPeer). This task requires that access to the web3.admin interface be available ( #12 must be complete).

[Game] Implement direct-to-table URLs

Implement custom URLs to directly join existing tables. The functionality should work in all runtimes so that players can share links with each other using external channels (chat, email, etc.)

[Game] Add check for in-use smart contracts during table creation

Add check for currently in-use smart contracts and disallow them from being selected/used when creating a new table.

[Game] Add account copy-to-clipboard button to Ethereum Account Widget

Add button to copy the currently-selected Ethereum account (in the Ethereum Account Widget), to the system clipboard.

Integration - JavaScript: Add personal, admin, debug access to integration script (cypherpokerlib.js)

Integrate access to the Ethereum client's web3.personal, web3.admin, and web3.debug interfaces into the CypherPoker JavaScript library (cypherpoker.lib) using: https://github.com/The18thWarrior/web3_extended (or similar scripts)

Game - ActionScript: Integrate POC updates into standard game client

Once #5 is functional the customizations for the limited POC should be integrated into the standard game client. In practically terms this means adding the various Ethereum integration calls from the POC into the same locations within the standard game client.

With #5 and this task completed, the full CypherPoker integration will support the ability to use secure cryptographic values.

[Game] Add runtime checks and workarounds for ".swf" export

Update the ActionScript source code to check for the Flash web runtime (".swf" file type), and add workarounds where necessary.

[Game] ActionScript: Optimizations

Include the optimizations currently implemented in the Rochambeau protocol in the main game code. These include:

1. Optional pre-generation/selection of shared prime (dealer mode)
2. Optional pre-generation of key pair
3. Optional pre-generation of card deck (dealer mode)
4. Optional pre-encryption of card deck (dealer mode)
5. Optional pre-mining of hand contract (dealer mode); may require local storage for addresses of unused contracts

[Game] Add player bets / chips information to player top bar

Add players' current individual bet and total chips information to the players top bar.

[Game] Revise table list UI

Revise the table list interface to make information more clear. The best way to achieve this is to expand the table selection button to fill most of the horizontal display area and revising the informational fields to make them more readable. Other buttons such as CREATE TABLE, JOIN TABLE, and CANCEL can be moved to the bottom of the display area.

This may make the table details UI unnecessary so consider removing it altogether.

[Game] Implement global/game settings update functionality

Implement functionality to upgrade global and game settings XML data between versions (e.g. v2.0a to v2.1a)

[Game] Add runtime checks and workarounds for ".air" export

Update the ActionScript source code to check for the generic AIR runtime (".air" file type), and add workarounds where necessary.

[Game] Implement customizable startup window dimensions

Implement customizable window dimensions for application startup via configuration data across all runtimes and include dynamic panel positioning.

[Game] Add all-in functionality / side pots

There is currently no all-in action. The only similar action is for a player to bet the maximum amount which is equal to the maximum amount of chips that any player at the table can bet. However, this is insufficient for all-in bets for games with more than 2 players as there may be some players that can match an all-in while others can't.

All-in betting should follow the rules defined Hoyle's Poker Rules: https://www.hoylegaming.com/rules/showrule.aspx?RuleID=222

[Game] Update blinds and betting order for heads-up play

Currently the order of betting in heads-up play is incorrect during the pre-flop phase. The dealer should place the small blind and bet first. In post-flop play it's the non-dealer player who should start betting.

Reference: https://en.wikipedia.org/wiki/Texas_hold_%27em#Betting_structures

[Game] Make blinds timer optional

Make the blinds timer optional for new tables.

[Game] Implement UI theme switching

Implement user interface theme switching to new Feathers controls. If possible it's preferable to do be able to do this live (while the application is running), rather than having to restart.

Game - ActionScript: Client user interface development

Implement the interface design specified in #9.

[Game] Add "dealer button" graphic to players top bar

Add a "dealer button" to the players top bar to indicate current dealer player.

Integration - JavaScript: Improve Ethereum integration script (cypherpokerlib.js)

• Test/update script compatibility for desktop version (AIR WebKit), and web version (Chrome, IE, Firefox, Safari)
• Add version support to all external functions (see commented section in pokerhandContract function)
• Add version 2.0 support for strings instead of current numeric parameters; numeric parameters should be parsed to string representations
• Review and optimize functions as required

[Game] Add handler(s) to Ethereum integration to indicate account lock/unlock status

Add an event dispatch to CypherPoker Ethereum JavaScript library to indicate account lock/unlock status and implement handler(s) in Ethereum integration classes for application-wide integration (e.g. usage in widgets)

[Game] Add configuration options for Ethereum client RPC-API address and port

Include user interface and settings data for Ethereum client RPC-API address and port settings in EthereumStatusWidget so that they can be dynamically set at runtime.

[Game] Add Slider component to renderer

Add the Starling Slider component to the StarlingViewManager renderer class so that it can be made available for use in widgets.

[Game] Implement password-protected tables

Add checks and implement user interface (dialog?) for joining password-protected tables.

[Game] Add warning/prevention dialog when attempting to join table with insufficient Ether

1. Add a a warning when joining a table with sufficient but low Ether (player may not be able to pay for a full hand).
2. Add prevention dialog when attempting to join table with insufficient funds for buy-in.

actionscript only ?

Sorry I had no idea how to contact you.
I think this p2p poker is genius, i'm far less enthusiastic with the actionscript client & I'd like to see if you'd agree to develop (with me or by guiding me so I can work fast) an html5/js client for desktop browsers. maybe also unity later on.
let me know, i'm looking for a poker engine to launch a new room & this p2p architecture could fit so well with my concept (but not the actionscript in browser !).
[email protected]

Design - CypherPoker logo

Create a new CypherPoker logo or revise the existing one:

The logo should include the name "CypherPoker" and two or more of the following themes:

• Poker
• Cryptography (encryption/decryption)
• Peer-to-peer (distributed/decentralized)
• Anonymity
• Cryptocurrencies (non-specific)

A number different versions of the logo should be prepared:

• Full: website header, desktop and mobile splash
• Reduced: desktop application icon and web favicon

Ideally the logo will be in vector format so that it can be scaled, and will come in both colour and black & white versions. The colour version may incorporate colours from standard card faces (white, black, navy blue, red, yellow), but other colours may be used if they enhance the design.

As part of the design consideration, if the logo includes both textual elements and graphical elements then an additional graphic-only version should be created for smaller uses (for example, for use as an icon).

Game - ActionScript: Rochambeau process fails after multiple rounds

The Rochambeau process occasionally fails after multiple rounds with the error:

28779: TypeError: Error #1009
    at p2p3::Rochambeau/sortWinningGames()
    at p2p3::Rochambeau/onGamePhaseChanged()
    at flash.events::EventDispatcher/dispatchEvent()
    at p2p3::RochambeauGame/updatePhaseChange()
    at p2p3::RochambeauGame/startDecryptSelections()
    at SetIntervalTimer/onTimer()
    at flash.utils::Timer/tick()

This issue appears with any number of players but is easier to reproduce with larger numbers of players (3+).

Test

Test

Smart Contracts - Solidity: Build a big/arbitrary-length integer math library

CypherPoker's smart contracts must be able to run positive integer calculations that exceed Ethereum's native 256-bit integer limit. This can be accomplished through a big or arbitrary-length integer library in Solidity that may be modeled on the one used in the game: https://github.com/monicanagent/cypherpoker/blob/master/Libraries/P2P3/CryptoWorker/src/crypto/math/BigInt.as

As a minimum requirement (additional functions may be required in the future), the library contract will need to support the following operations:

(x^y) mod z

Or:

"x" to the power of "y" modulo "z"

Within the 256-bit limit, this can be natively expressed in Solidity as:

uint256 result=(x ** y) % z;

Since each operation here is discrete, the result of (x ** y) must be within the 256-bit limit which requires input values that are too small to provide any security.

In a non-arbitrary library implementation each parameter must support a positive integer value up to 2048 bits but ideally parameter sizes would be arbitrary.

Although Solidity requires two discrete operations (exponentiation & modulo), the ideal implementation would efficiently handle both as one.

Design - Game client user interface

Because of its cross-platform nature the game client must support a number of base resolutions. In the initial design proposal the concept is to use one dynamic display for all supported resolution. The main interface would be centered and top-aligned within the smallest supported viewport area (800x600), and the player's private cards would be slightly larger and be positioned above the smaller community/public cards:

The initial UI elements/statistics that should be accommodated in the main interface include:

• Player's current bet (10-20 digits plus currency symbol)
• Player's balance (10-20 digits plus currency symbol)
• Bet / Raise / Call / Check button (may be individual buttons or appear in the same spot and made visible based on the current betting context)
• Fold button
• Blinds timer (countdown clock)
• Panel access (see below)
• Opponent(s) status: dynamic area that includes player avatar (possibly video), name, balance, current action (determining dealer, generating game, betting, encrypting, decrypting, watching)
• Player (local) status: dynamic area that includes the current action (determining dealer, generating game, betting, encrypting, decrypting, watching), and may include a local loopback video area (webcam).

In the initial design proposal the main interface area would be flanked by three panels that, when triggered by some element, would slide into position to cover most of the viewport on devices with smaller resolutions. These panels would contain all non-essential options, features, and statistics so they may remain hidden most of the time.

Because the number of options and settings is expected to be high, panel content should be scrollable or paginated.

For higher-resolution devices the panels would expand to fill the available area.

This panel expansion could be static (panels would remain at set dimensions from startup), or dynamic (panels currently in context would fill the visible while non-contextual panels would shrink).

While the content and resolution restrictions must remain, this preliminary design concept is intended only as a starting point. For example, if another design can accommodate the required main interface elements and has an efficient way to access a large number of secondary settings and statistics then then centered-with-panels approach may be dispensed with.

In all designs, any interactivity and animations must be described (e.g. "panel slides left until right edge is aligned with display edge"), and user interface elements should always include "enabled", "disabled", and "active" states (hover is omitted for cross-compatibility).

In addition to decorative elements, designs for cards may also be included. For best results these should be in vector format. For example:

https://github.com/notpeter/Vector-Playing-Cards/tree/master/cards-svg
https://code.google.com/archive/p/vector-playing-cards/downloads
https://github.com/GavinJoyce/PokerCards/tree/master/images
etc.

Game - ActionScript: Full hand deal on game startup, crash

A full hand is automatically dealt during which the game places 0 bets on players' behalves. At the end of the hand the game may crash with a runtime error.

This issue is not always reproducible and appears most commonly when running multiple instances on the same machine which suggests a startup-message/initialization sequencing problem.

News?

Are there any news about the project? Is it still alive?

[Game] Add runtime checks and workarounds for mobile export

Update the ActionScript source code to check for mobile runtimes and add workarounds where necessary.

Game - ActionScript: Missing big blind action on initial round of betting

During an initial betting round of a new hand (after the hole cards), the big blind should be given a chance to raise before the community cards are dealt. Currently this action is skipped and the community cards are dealt directly.