This time, it's personal.

While I was working on the Solidity abitrary-length integer math library, the admittedly hefty contract suddenly stopped working when being published to the local Web3 Provider Endpoint (Geth client at “localhost”).

I suspected (since no error was reported), that this was a problem with the initial gas amount being supplied to the contract; it would work fine if I pasted it into Geth from the “Web3 deploy” output of Browser Solidity with an updated “gas” parameter but would fail if I simply clicked “Create”.

It seems I wasn’t the only person experiencing this issue but unfortunately I wasn’t able to find any solutions so I decided to do some digging into the code. The following response, originally posted in the Ethereum Community Forum, reflects what my digging unearthed. Maybe it’ll help you if you’re running into similar issues.

I’m not sure if there exist any tools to do specifically what you describe but after running into the same problems and doing some testing I’ve found what appears to be a code-level solution that may work for you. I’m not in any way associated with the Ethereum project so what I’m describing here is 100% unofficial (use at your own risk).

The first solution applies to a self-hosted compiler – when you run Browser Solidity from your own web server – the second applies when running it from the officially hosted location (

Self-Hosted Solution

Update the file “app.js” in the “build” folder of your installation. Find the function UniversalDApp.prototype.runTx (currently on line 99455). Scroll down and find the following line:

var gas = self.options.getGas ? self.options.getGas : 1000000;

Comment this line out and replace with:

var gas=30000000;

(or whatever you want the default gas amount to be)

Replace the file on the web server and reload the app to use the new gas amount.

You may also be able to set the self.options.getGas value but since I’m not sure what else this may effect I can’t recommend doing this.

Officially-Hosted Solution

Download a copy of the “app.js” file to your local computer ( Update the file as described above.

Download and install a web debugging proxy like Fiddler or Charles. Use the autoresponder (or analogous) feature of the software to respond with your local file whenever the browser attempts to load the .js file from the official URL.

Here’s a sample Fiddler configuration that loads the “app.js” file from my desktop (obviously your local path will differ):


Note that you need to ensure that “Unmatched requests passthrough” is enabled otherwise all other requests will fail and the app won’t load.

In Charles this functionality is called “Map Local Tool” (, and it may also be possible to do this using your browser’s built-in tools or plugins.

Either way, be sure to reload the site to ensure that the browser picks up the updated .js file.


P.S. You can also use my customized version of Browser Solidity. The gas amount has been increased to 200000000 and the app is delivered over HTTP so there should be no security domain issues when communicating with Geth:

June 20th, 2016

Posted In: Development / Coding, Internet / Web

Tags: , , , , ,

Leave a Comment

A commenter on my last post mentioned that although the explanation of CypherPoker’s cryptography was accessible it was altogether too long; a five-year-old’s attention span probably won’t get them through the material.

That’s fine, I replied, because understanding the underlying math is not necessary to understand how CypherPoker works. Here are a series of sketches I produced a while ago that will hopefully prove this point:

Bob and Alice are going to play a game of Texas Hold'em poker. Bob will be the initial dealer.

Bob and Alice are going to play a game of Texas Hold’em poker. Bob will be the initial dealer.

Bob has a deck of 52 cards, 52 identical lock boxes, 52 identical locks, and a key that opens the locks.

Bob has a deck of 52 cards, 52 identical lock boxes, 52 identical locks, and a key that opens the locks.

Bob places one card from the deck into each box...

Bob places one card from the deck into each box…

...applies one lock to each box...and shuffles them.

…applies one lock to each box…and shuffles them.

Next Bob sends the locked and shuffled boxes to Alice.

Next Bob sends the locked and shuffled boxes to Alice.

Alice also has 52 identical locks and a key to open them. She applies these locks to the boxes.

Alice also has 52 identical locks and a key to open them. She applies these locks to the boxes.

Alice also shuffles the boxes so that now neither she nor Bob know which cards are in which box.

Alice also shuffles the boxes so that now neither she nor Bob know which cards are in which box.

Bob now selects 2 boxes containing his private/hole cards and asks Alice to remove her locks from his selections.

Bob now selects 2 boxes containing his private/hole cards and asks Alice to remove her locks from his selections.

Alice removes her locks and gives her singly-locked boxes to Bob.

Alice removes her locks and gives her singly-locked boxes to Bob.

Bob removes his locks from the 2 boxes and takes out the cards inside. Alice doesn't know what private/hole cards Bob now has.

Bob removes his locks from the 2 boxes and takes out the cards inside. Alice doesn’t know what private/hole cards Bob now has.

Now Alice selects 2 locked boxes containing her private/hole cards and asks Bob to remove his locks from her selections.

Now Alice selects 2 locked boxes containing her private/hole cards and asks Bob to remove his locks from her selections.

Bob removes his locks and gives the singly-locked boxes to Alice.

Bob removes his locks and gives the singly-locked boxes to Alice.

Alice removes her locks from the 2 boxes and takes out the cards inside. Bob doesn't know what private/hole cards Alice now has.

Alice removes her locks from the 2 boxes and takes out the cards inside. Bob doesn’t know what private/hole cards Alice now has.

Now that Bob and Alice have their private/hole cards they proceed to bet until they're ready to see the flop cards.

Now that Bob and Alice have their private/hole cards they proceed to bet until they’re ready to see the flop cards.

Bob now selects 2 locked boxes containing the flop cards, removes his locks, and gives the boxes to Alice who also removes her locks. The cards in the unlocked boxes are the public/community flop cards.

Bob now selects 2 locked boxes containing the flop cards, removes his locks, and gives the boxes to Alice who also removes her locks. The cards in the unlocked boxes are the public/community flop cards.

After another round of betting the next public/community card is selected. Alice may also choose the locked boxes containing these cards (public/community) and she does so now. After removing her lock she gives the box back to Bob who removes his lock to reveal the card.

After another round of betting the next public/community card is selected. Alice may also choose the locked boxes containing these cards (public/community) and she does so now. After removing her lock she gives the box back to Bob who removes his lock to reveal the card.

After one final round of betting a final locked box is selected containing the river card. Both Bob and Alice remove their locks to reveal the card, compare hands, and declare a winner.

After one final round of betting a final locked box is selected containing the river card. Both Bob and Alice remove their locks to reveal the card, compare hands, and declare a winner.

You’ll note that additional services such as those provided by Ethereum are not included here since they are not part of the core CypherPoker code but rather are used by the game to hold wagers and to verify the game. The Ethereum integration topic would make for a great follow-up post but what I’ve described so far describes the bulk of CypherPoker game play. And no math 🙂

May 2nd, 2016

Posted In: Internet / Web, Security

Tags: , , , , ,

Leave a Comment

I’ve recently had the opportunity to run over this topic with someone who I’m quite certain isn’t 5, mentally or otherwise, so the title isn’t meant pejoratively but rather as being reassuringly easy to understand. Please don’t be concerned by the length of the post – it’s mostly examples and demonstrations. To see all of this in action or to learn more please visit to join the Slack, drop by the GitHub repository, or visit the subreddit .


CypherPoker uses a short mathematical equation to encrypt (hide) or decrypt (reveal) information such as cards that can be represented by numbers (1=Ace of Spades, 2=Two of Spades, etc.) An important property of this mathematical equation is that when information is encrypted by multiple players, it can be decrypted by those players in any order – as long as everyone who encrypts also decrypts – kind of like a multi-lock box.


No fancy numbers

The encryption/decryption system used in CypherPoker uses numbers known as “positive integers“. This means simply that the numbers it uses are whole numbers – no fractions with remainders or decimal point values – and they’re all positive, or equal to or larger than 1. (We omit 0 since we can’t really use it).

Here are some examples of numbers that are positive integers:


Here are some examples of numbers that are not positive integers:


The secret sauce

Here’s the mathematical function that’s used to encrypt or decrypt information:

mK(mod P)

Sometimes this is written as:

(m^K) mod P

In JavaScript it would look like this:

Math.pow(m,K) % P

You’ll probably recognize the “mK” part which means “m” to the power of “K”, or “m” multiplied by itself “K” times. (I’ll explain why we use the letters “m”, “K”, and “P” in a bit)

Here are some examples:

64 = 6 x 6 x 6 x 6 = 1296
93 = 9 x 9 x 9 = 729
3211 = 32 x 32 x 32 x 32 x 32 x 32 x 32 x 32 x 32 x 32 x 32 = 36028797018963968

You can do this calculation by hand or on a calculator by entering the value for “m”, pressing the “xy” key, entering a value for “K”, then pressing “=”.


Once we calculate mK we do a modulo operation on the result – the “mod” part. This is also something that you can calculate by hand or on a calculator by entering the result of “mK“, pressing the “MOD” key, entering a value for “P”, and pressing “=”.


Modulo simply “wraps” a number around some maximum value just like an analog clock which is why it’s sometimes called “clock math”.

To understand this, consider the standard 12-hour analog clock:

Analog clock

In our day we have 24 hours but on this kind of clock we can only show 12. The first 12 hours are fine but at noon, or 12 o’clock, the clock basically resets (to 0), so that the next hour is 1 o’clock.

If we kept counting beyond 12, 1 p.m. is actually hour 13, 2 p.m. is hour 14, 3 p.m. is hour 15, and so on:

24-hour time

We could keep going around and around on the clock any number of times and land on some number between 0 and 11 (we would never get 12 since the count resets at that point to 0).

Modulo clock

The result of the modulo operation tells us which number we’ll land on if we go “x” number of hours around a clock with “y” divisions, or:

x mod y

An analog clock has 12 divisions so the math would look like this:

x mod 12

If we want to find out what hour 13 is on our analog clock with 12 divisions we would calculate:

13 mod 12 = 1

If 2927 hours passed on the same clock, what number would we land on?

2927 mod 12 = 11

The clock we use doesn’t need to have 12 divisions, it can be any positive integer such as 38:

x mod 38

…or 1001:

x mod 1001

…or 3:

x mod 3

There are ways to do this math with numbers that aren’t positive integers but that doesn’t happen in CypherPoker.

Putting it together

Back to:

mK(mod P)

The “m” stands for the message to be encrypted or decrypted. This is actually just a number but it can represent quite a few different things; it could be a letter of the alphabet (2=A, 3=B, 4=C…), a coordinate on a map, or maybe a playing card (2=Ace of Spades, 3=Two of Spades, 4=Three of Spades…) Although we can use any positive integer for “m”,  1 to the power of anything will always produce the same value as we started out with so we don’t use it (or 0, for similar reasons).

The “K” value is the encryption or decryption Key. This is a number (of a pair), that is calculated using the “P” value (below) and kept secret by the player.

The “P” value is a Prime number. A prime number is one that can be evenly divided only by itself and 1. Another way to put it is that “P” divided by any positive integer other than itself and 1 will always produce a result that’s not a positive integer. For example, 5 is a prime number because:

5/5 = 1
5/4 = 1.25 
5/3 = 1.666666…
5/2 = 2.5
5/1 = 5

But 4 is not a prime number because it can be evenly divided by 2 (the result is a positive integer):

4/4 = 1
4/3 = 1.333333…
4/2 = 2 (not a prime!)
4/1 = 4

If a number isn’t a prime number we call it a “composite” number.

Finding a keypair

We use one value for “K” to encrypt, scramble, obfuscate, or hide the “m” value, and another value for “K” to decrypt it, or work in the reverse direction. Since these values come in pairs, together they’re called a “keypair”.

To find keypairs for “K” we find something called a “modular multiplicative inverse”. This simply means finding two values, the keypair “a” and “b” which make the following equation work:

(ab) mod (P-1) = 1

This is sometimes written as:

(a*b) mod (P-1) = 1

In JavaScript it would look like this:

if ((a*b) % (P-1) == 1) {
   //a and b are a valid keypair
} else {
  //a and b are NOT a valid keypair

This means that if you multiply “a” times “b” and modulo the result by “(P-1)” it must produce 1.

In CypherPoker every player knows the value for “P” before the game begins; let’s say it’s the prime number 11.

To find keypairs we could simply try every combination of numbers between 1 and 10 (or P-1) to see which ones satisfy the equation.

After lots of calculations we would find two pairs of numbers that work:

….since (3 * 7) mod 10 = 21 mod 10 = 1

…since (9 * 9) mod 10 = 81 mod 10 = 1

Keypairs are usually written as (a,b). For example: (3,7) or (9,9)

In the above example we have only 2 keypairs available which means that the encryption system isn’t going to be very secure but the math will work regardless.

Let’s do some crypto…

To encrypt “m” we use one of the keypairs we found above for “K” and the shared “P” value.

For example, let’s say we want to encrypt 2 (which we’ve decided represents the Ace of Spades). We already know that “P” is 11 and we used that to calculate our keypair of (3,7), so the encryption calculation is:

23 mod 11 = 8

To decrypt we use the same function, this time using 8 for the encrypted “m” value (from above), and the other half of the keypair for “K”:

87 mod 11 = 2 (Ace of Spades)

Once we’ve encrypted “m”, the result can again be encrypted again. This can be done over and over and as long as every encryption is followed by a matching decryption we will get back the original value for “m”. Most importantly, all of the encryptions and decryptions can be done in any order.

Here’s an example using both keypairs – (3,7) and (9,9) – to encrypt the Ace of Spades twice:

23 mod 11 = 8
89 mod 11 = 7 (the final encrypted or “face-down” card)

Using the other half of the keypairs we can now decrypt:

79 mod 11 = 8
87 mod 11 = 2 (Ace of Spades)

This works even if we decrypt in a different order:

77 mod 11 = 6
69 mod 11 = 2 (Ace of Spades)

Just a moment

Unfortunately there’s a bit of a problem with using just any number for “m”. It turns out that the “quadratic residue modulo P” of the “m” number will be the same no matter how many times you encrypt it.

Although it sounds pretty fancy, the quadratic residue calculation (also known as the Legendre symbol), is no more difficult than everything else we’ve done:

m(P-1)/2 mod P

This may also be written as:

(m^((P-1)/2)) % P

…or in JavaScript:

Math.pow(m, (P-1)/2) % P

This calculation will always produce either P-1, 0, or 1. In other words, if P=11 then the above equation will always produce either a 10, a 0, or a 1.

Check it out:

2(11-1)/2 mod 11 = 210/2 mod 11 = 25 mod 11 = 32 mod 11 = 10
3(11-1)/2 mod 11 = 35 mod 11 = 243 mod 11 = 1
4(11-1)/2 mod 11 = 45 mod 11 = 1024 mod 11 = 1
5(11-1)/2 mod 11 = 55 mod 11 = 3125 mod 11 = 1
6(11-1)/2 mod 11 = 65 mod 11 = 7776 mod 11 = 10
7(11-1)/2 mod 11 = 75 mod 11 = 16807 mod 11 = 10
8(11-1)/2 mod 11 = 85 mod 11 = 32768 mod 11 = 10
9(11-1)/2 mod 11 = 95 mod 11 = 59049 mod 11 = 1
10(11-1)/2 mod 11 = 105 mod 11 = 100000 mod 11 = 10

When the result is 1 we say that it’s a “quadratic residue” and when it’s P-1 we call it a “quadratic non-residue”. When the result is 0 it has no special name since only 0 will produce it.

Now remember when we encrypted the number 2 (the Ace of Spades) above with the keypairs (3,7) and (9,9)? Quick refresher:

23 mod 11 = 8
89 mod 11 = 7 (the final encrypted or “face-down” card)

Here we can see that 2 is encrypted to 8 which is then encrypted to 7. If we look at the quadratic residue calculations we did above we notice that 2, 8, and 7 are all quadratic non-residues (10).

As part of our decryption we also ended up with 6:

77 mod 11 = 6

And wouldn’t you know it, 6 is also a quadratic non-residue!

It doesn’t matter how many times or with which keypair you encrypt the value 2; when “P” is 11 the encrypted results will always be quadratic non-residues. Similarly, if we encrypt the value 9 (“m” is 9) we would find that all of the results would be quadratic residues just like 9 itself.

If 2 represents the Ace of Spades, 3 is the Two of Spades, 4 is the Three of Spades, and so on, then we know some information about cards that have been encrypted. After all, even if we don’t know exactly which card an encrypted value represents, we know that if it’s a quadratic residue it can’t be the Ace of Spades (since that is a quadratic non-residue).

It sure would be handy to be able know that your poker opponent(s) definitely can’t be holding certain cards, wouldn’t it?

That’s why in CypherPoker the numbers representing cards are only quadratic residues. For example, if “P” is 11 then our cards would be:

3=Ace of Spades
4=Two of Spades
5=Three of Spades
9=Four of Spades

To make sure that our cards don’t “leak” information we can’t use any of the other numbers because they’re all quadratic non-residues.

The nutshell

When “P” is 11 we only have 4 secure cards and 2 keypairs which doesn’t make for a good or secure game of poker. In order to support a full 52-card deck (as quadratic residues) and have enough keypairs to make it nearly impossible for someone to find the one that we chose, the “P” value must be much larger.

As a security baseline, CypherPoker uses numbers that are 512 bits. That means that “m”, “K”, and “P” are all between 0 and:

2512 = 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096

(here’s a large integer calculator you can use to see how I produced these results:

For truly secure games we would probably want to use a 1024 bit number (or larger). That means that “m”, “K”, and “P” are all between 0 and:

21024 = 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216

Once we start to work with numbers this big it’s hard just to do the basic math let alone find shortcuts to make it faster, and that’s where the security of the encryption lies.

The trick in any good implementation is to be able to perform these large-integer calculations efficiently but this is a problem for which a solution must be found specific to whatever technology is being used. Some programming languages, for example, support large or arbitrary-length integer math natively (without any external libraries or additions), but in most cases developers will need to find or write a suitable solution. The arbitrary-length integer math library used in CypherPoker, for example, is the JavaScript-based BigInt.js by Leemon Baird.

Nevertheless, regardless of how the math is handled it must produce the same results as we’ve covered here so it’s safe to say that if you’ve understood everything above you also understand, at a fundamental level, how CypherPoker encryption and decryption work. Congratulations! 😀

April 18th, 2016

Posted In: Development / Coding, Internet / Web, Security

Tags: , , , , , , ,


As I write this the Ethereum “Homestead” hard fork event has just passed and I can think of no better time to announce that the proof-of-concept integration between CypherPoker and Ethereum is now available!

This is pretty exciting news because it demonstrates how Ethereum’s smart contracts are used to provide game verification and escrow services in lieu of a trusted third party.

I’ll be the first to admit that my first kick at the can was somewhat clumsy but in my defense I hadn’t even heard of Solidity until about four months ago. Since then I’ve crafted a variety of smart contracts that together provide services for cryptographic poker game play: decryption support, poker hand analysis, betting tracker, and so on. They’re by no means ready for anything other than a proof-of-concept, but that was the point 🙂

For the POC the CypherPoker game client had to be “dumbed down” significantly, meaning that it was restricted to using numbers so small that they offer no security whatsoever. This was done in order to accommodate Ethereum’s native 256-bit limit. I’ll go into detail about this at some future time but suffice it to say that incorporating the POC game client changes into the trunk repository should be fairly easy, it’s the smart contract portion that’s going to be most challenging since it will probably require building a big or arbitrary-length integer math library.

Nevertheless, this milestone provides an excellent foundation for future development and projects like BTC Relay hint at tantalizing future directions. With the project growing I’m now taking a breather to reach out to the community – there are many new changes and new tasks that need attention, not to mention the timely discussions to be had around how a decentralized autonomous organization could reward contributors to the project. Please visit the updated site to see what’s new and what’s next, and be sure to drop by the CypherPoker Slack or subreddit to chat and discuss.

March 14th, 2016

Posted In: Development / Coding

Tags: , , , , , , , , ,

Leave a Comment

This past year was certainly exciting for Sarah and me.

Although she wasn’t involved in the direct development of the project, she regularly allowed me to bounce ideas and explanations off of her in order to refine how I present them. The need to get concepts across in a cohesive, friendly, but accessibly concise way will become increasingly important and I’m immensely grateful to her, and others, for providing me with an audience and support.

I’ve tried to faithfully record these ideas as I went along and this, along with a full-time job, had slowed down development considerably.

Then this fall I was let go from said job. I was very thankful for what I consider a generous severance so we weren’t left in freefall, but this wouldn’t last forever. We worked out a budget and agreed that unless we could figure out some other way that we could support ourselves by the end of November that I should be looking for work.

On the last week of November we started a crowdfunding campaign but its plug was pulled in about a day and a half. The campaign site provider sent me a non-existent explanation (they’ve since added it), but they transferred the donations that had already been made so it was hard to bear a grudge. Still, although it seemed possible that a crowdfunding campaign would work, it left us with few options.

We couldn’t find a well-recognized provider that didn’t explicitly state that they wouldn’t hesitate to yank our campaign if it even remotely involved gambling. I decided I would do whatever it took so I added a Bitcoin address for donations to the CypherPoker play/test site, posted an open question about feasible alternatives on Reddit, started reviewing the job market, and began to look for my most recent resume.

With a single Bitcoin donation, a cold and grey December rolled into town and the job hunt had turned up no good results yet. We would be able to stretch out our budget a bit but we were definitely operating on the thin end of the dime. The holidays weren’t looking very pretty.

I truly believed that CypherPoker was bound to catch on eventually but treading water with no land in sight can be a little unnerving. Maybe this was not yet the time?  I could try getting back into the coffee-serving game; wonder if those Reddit posts got some responses.

It turned out that Reddit had something much better.

In a private message someone requested a meeting to discuss my funding needs. And could we do it in person. It didn’t take me long to respond 🙂

I’m happy to report that after a few meetings we’ve been thrown a generous lifeline and the project is moving along at a good pace.

If you’ve been following some of my updates you’ll know that the base CypherPoker game is essentially complete. Optimizations, bug fixes, and improved integrity checking are still on my to-do list but now I’m also looking at cryptocurrency integration. It’s this last part that seems to be garnering the most attention for the project (which I fully understand). Unfortunately it’s also the most cutting-edge so there’s not much material to draw on.

I always assumed that some sort of escrow system would be needed but everything that I considered had the problem of colluding verifiers/escrow-holders. I explored options with reputation ratings that would establish trusted verifiers but collusion problems again popped up. Something else was needed, but what?

It was suggested that I look into something I hadn’t yet considered: smart contracts.

After doing some research I came to the conclusion that smart contracts might just be the solution I’d been looking for. I began to experiment in order to better gauge their effectiveness and although I’m still working out some of the details the preliminary results look very promising. I may have to push existing smart contract technology to its limits but so far everything is looking feasible.

All the pieces are falling into place and I’ll have a much better idea of where everything stands in early 2016. Some of the other options I’d mulled over for CypherPoker, such as using Tor or I2P for anonymity (and some DDOS protection), are still part of the plan and in fact it’s looking like smart contract technology will help to answer some of the questions about how these would work.

I’ll be writing more about these developments once I’m satisfied that I have something beyond the merely experimental but there should be lots of news to share with you in the coming year. Even if perfection is always in the next version, I believe that 2016 will be the year when we see the world’s first fully integrated peer to peer poker game, one that incorporates a cryptographic game with cryptocurrency support, automated and provable verification, and anonymity.

Here’s wishing you and yours a safe and enjoyable holiday, and a new year as filled with excitement as I’m sure ours will be!

December 25th, 2015

Posted In: Internet / Web, Social Trends

Tags: , , , , , , , , , , , , ,

Leave a Comment

I joined Cryptologic in early 2013, about a year after it was acquired by Amaya. I’d worked in the online gaming industry for a number of years prior to this and I’m pretty sure that my experience gave me an advantage over other developers vying for the same job. Later on I would discover that I had even more of a leg up as some higher-ups has rooted for me, having known me from my past jobs.

It’s something that I already knew but the professional game development industry in Toronto, especially online gaming, is a small one indeed. A couple of years later, when Amaya made the stunning purchase or PokerStars / Full Tilt, this fact would once again be underscored as I met a number of people from my past who were now working for the online poker giant.

My interaction with PYR Software, the company that develops and maintains the PokerStars / Full Tilt software, was somewhat limited but certainly instructive. Besides getting a small peek inside their software I was given a good idea of the direction that they were heading in and why we were making regular visits to their Richmond Hill offices: we would be integrating our products in order to expand their poker-only offering. At that time Amaya was pushing hard to expand back into the once-lost US market by targeting New Jersey which was keen, or so it was claimed, to capitalize on the insatiable demand for online gambling.

Not long after the acquisition Amaya sold its Cryptologic and Chartwell divisions to NYX Gaming which decided that fat needed to be trimmed and I was let go. The New Jersey market has yet to materialize.

I was disappointed with the somewhat sudden changes but the severance package I received, not to mention my experiences working for Amaya, has left me with nothing but pleasant nostalgia. Online gambling may seem to be a shady business, and my positions prior to Amaya suggest that sometimes it is, but as an employee of the PokerStars owner I’ve had very positive experiences. Sure I may have had disagreements about how they went about things sometimes but in the end they were a damned good company to work for and I would give it serious consideration if they ever asked me to return.

I also can’t say that I ever had any indication that Amaya was anything but forthright in their dealings. Any criticisms I may have had were concerned with efficiency and priorities but I’ve always seen these as being ultimately business and process decisions, and my views as coming from a lowly developer viewpoint. I understood that my take was hardly holistic and while I expressed any concerns that I may have had I didn’t dwell on them.

I need to stress the above points because the following views are founded on much the same basis. I must also emphasize that although some people may view CypherPoker as a challenge to PokerStars / Full Tilt, it was never intended to be anything other than a very modest alternative. I was extremely careful to segregate my work on the project from my Amaya work, even going so far as to eschew the early name of CryptoPoker because it was too close to Cryptologic. Besides, CypherPoker left the starting gate as a free and open-source project that PokerStars / Full Tilt will always be welcome to incorporate into their operations with my blessings.

Having said all that, I’m genuinely perturbed by the direction that Amaya is taking PokerStars in. In a nutshell, they are limiting their higher-stakes games in 2016, sometimes quite severely, in an attempt to bolster their audience:

The reason we are focused on the highest status levels is because these rewards have become so enticing that we have inadvertently altered why some people play and how they play. We are introducing these changes to move towards a more balanced long-term poker economy and to return the game back to one that rewards skill via winning at the tables rather than playing primarily for volume.

This has stirred a considerable backlash in online forums and even inspired a player 48-hour player “strike”. PokerStars’ own celebrity spokesperson Daniel Negreanu has expressed concerns over how the company went about introducing the changes and other big names have expressed deeper misgivings over the announcement.

Personally I understand the wish to create a leaner operation under the new corporate ownership but it seems like Amaya is tinkering with a pretty well-balanced formula and perhaps to its own detriment. I was equally dubious when online rumours of a PokerStars casino, which was then in its very early and unannounced  stages, were making the rounds. I knew the rumours to be true since I was actually working on the project and I also had an inkling as to how people would react to it; in short, not very positively. Online poker players were especially critical of what they viewed as a way to sucker people out of their money.

To me it came down to simple profitability as was (probably) required by new corporate demands, and it would be achieved without much input from the very community that was expected to make it happen. Even though at the time I was working at an arm’s length from PokerStars, or perhaps because of it, I was able to see a disconnect between what the corporation wanted and what the players requested. Based on the feedback I’ve seen online, the recent decision by PokerStars is continuing this trend.

Once again I must remind myself that I don’t really know what’s happening at most levels of the company so my analysis is myopic at best. However, it seems like bad practice to disenfranchise players with sweeping changes that according to the company spokesman were very poorly communicated and not requested. I don’t believe that PokerStars is in such bad shape that it can’t swallow slightly smaller profits in order to make existing players happy and encourage new ones to reach for poker stardom, so I’m left with the impression that this is all intended simply to create extra profits for shareholders and investors who may not care much about PokerStars or online poker in general.

If this is true then it doesn’t bode well for the future of online poker as it stands today. If profits are primarily what’s driving the world’s biggest online poker site then I expect that many players will either look to alternatives or resolve themselves to grinding away until something better comes along. Even though it’s not exactly the same, perhaps CypherPoker will be that thing, or perhaps PokerStars will reverse their direction. Either way it’s my sincere hope that online poker players keep hope in the future because one way or another things are bound to get better.

December 4th, 2015

Posted In: Development / Coding, Internet / Web

Tags: , , , , , , , , , ,

One Comment

I while ago I put together a video demonstrating how to compile CypherPoker to play over the internet (rather than just LAN/Wireless LAN).

Since then the software has been updated to support this functionality more generically and private internet games are now segmented by a “private game identifier” (that’s the name I’m using for now anyways). You can try it out at  – instructions are found on the page.


Similarly to the video, this solution uses Adobe’s Cirrus service to introduce peers to each other when playing over the internet/web.

Unfortunately, being a developer test service means that Cirrus isn’t suitable for dependable or broad-based deployment. Besides, it’s somewhat iffy describing CypherPoker as peer-to-peer software when it requires a centralized, corporate-branded service.

Had I not discovered the OpenRTMFP/Cumulus project early on in my experiments with RTMFP I might have eschewed the protocol altogether, but not only has the rendezvous server continued to be developed but it’s also spun off the even more robust MonaServer. The software now supports a mix of RTMFP/RTMP/RTMPE, HTTP, and Websocket protocols with built-in support for JSON-RPC and XML-RPC, which should allow it to scale nicely beyond ActionScript in the future. In addition to this, both Cumulus and MonaServer come with support for the LUA scripting language which makes them suitable for a wide variety of applications.

While it’s not the only type of connectivity that I’d like to see in CypherPoker, in this post I’m going to briefly discuss how MonaServer can be used to establish assisted peer-to-peer networking without relying in any third-party service such as Cirrus. Put another way, we’ll be examining how to set up your own Cirrus-like rendezvous service for CypherPoker.

First you’ll need to grab a copy of MonaServer. If you want to build your own version from scratch you can follow the instructions on the project’s site, but for this tutorial we’ll use the standard precompiled Windows version as-is. For this I’ve created a ZIP file containing both MonaServer and the web version of CypherPoker that you can download here.

Just unzip the file and execute run.bat; this’ll start up MonaServer with default settings and then after a brief delay it will launch two instances of CypherPoker in your default browser. MonaServer takes care of both serving the game files in the “www” folder over HTTP and connecting the instances for peer-to-peer networking over RTMFP. It’s worthwhile to note that the CypherPoker files could just as readily be served from an entirely different server such as Apache on an entirely different computer; we’re just using MonaServer for both purposes here.

The server software will listen to UDP connections on port 1935, the default for RTMFP, and port 80 for HTTP transactions over TCP. These and many other defaults can be changed quite easily if desired or required – for example, if you’re already running a web server on port 80.

CypherPoker gets its default server information for internet/web play from the “RTMFP_INET” definition of the settings.xml file in the “www” folder:


The address “rtmfp://localhost/” will probably also work just as well and if we’re using a non-standard port it can simply be appended to the server URI. For example, if MonaServer has been configured to listen to RTMFP connections on port 2968 the <serverAddress> node would look like this:


In terms of client and server setup there isn’t really much more to do. However, the rendezvous service isn’t going to be terribly useful if it’s only accessible within your own local network so there are a couple of other things that need to be set up.

If this is your first time I’d recommend reading up on some of the potential pitfalls of hosting your own server as well as acquainting yourself with some of the background concepts. Be sure that you’re comfortable with changing both your router settings and Windows firewall and that you understand the implications before embarking on the next steps; you’ll be opening up part of your network and computer to random internet traffic and not all of that traffic is friendly.

Step 1 – Update your firewall

First you’ll need to update your Windows firewall settings. The first time that you run MonaServer Windows will ask you what type of firewall permissions to grant it. You should enable both private and public networks:


If you missed this part or didn’t select both options you can always start the firewall manager by running \Windows\System32\WF.msc, or by searching for “Windows Firewall with Advanced Security” in the START menu search field. In the open manager select “Inbound Rules” and find “monaserver.exe”.


Right-click on the entry and select “Properties” from the context menu. You’ll probably want to explore some of the other filtering features available but for now we just want to make sure that the rule is enabled, that connections are allowed in the “General” tab…


…and that both “Private” and “Public” profiles are selected in the “Advanced” tab:


Next we’ll want to make note of our machine’s subnet address. To do this, launch the command prompt by typing “cmd” into the START menu search field and then “ipconfig” in the opened command prompt window. This will display your current network adapter configuration and your machine’s local IP address:


Step 2 – Update your router

The next step will require you to update some settings on your router in order to allow outside (internet) traffic through to your computer and to MonaServer.

Unfortunately there are many routers on the market so attempting to cover them all here isn’t possible but there’s an excellent resource available at:

What we want to accomplish is to forward external traffic on the specified ports to the computer with MonaServer. Some routers do this by binding to a specific subnet IP, which is why we looked it up earlier, and some routers identify the computer by name so you only need to select it from a list.

We’ll want to create two entries for our MonaServer computer, one for UDP port 1935 and one for TCP port 80, assuming you’re using the default settings for the server and that we’re using it both to serve the game files and to provide a rendezvous service.


You can do fancier mapping here if desired but I’ll leave it up to you to do the research on how that’s done with your specific router.

One final step you may wish to take with your router is to assign a static, fixed, or permanent IP to the computer running MonaServer so that you won’t have to repeat these steps if the computer’s subnet address changes, which may happen anytime that it’s disconnected from the network for a period of time. This can by done by updating Windows’ networking settings or (often) on the router.


Now that we’ve set up the router to allow and forward internet traffic through to MonaServer we have only two steps remaining.

First we need to find out what our public IP is since the address we’ve seen so far is internal to our own network only. Simply visit or any similar service and note the public IP listed there.

Finally, update the CypherPoker settings.xml file with the external IP. For example, if our public IP is and we’re using the default RTMFP port (1935), the settings data would look like this:


If we’re using a non-standard port such as 2096, for example, we simply add the custom port to the URI:


As mentioned earlier, because of this configuration data the CypherPoker files can be served from a completely different web server and the software will communicate with the RTMFP rendezvous service running on our machine. However, if we’re using MonaServer to serve both web content and connect RTMFP peers we can now simply load the software from, and have it connect to, the same server. Using our example public IP from above this would be something like:

Using a direct IP address like this isn’t the nicest solution from a player perspective but it works well. We could make this a little more friendly by mapping our public IP to a domain name by using a service like No-IP or, better yet, we could host the CypherPoker files on a remote web server with our own registered domain which will make it appear to players as though the game is running from there. With the AIR versions of the game (desktop/mobile) this would be even less visible as the game would just connect and work (as long as MonaServer is running on our machine).

RTMFP is a great protocol because of the features it provides beyond mere peer-to-peer messaging, features like audio/video streaming and (nearly) effortless data sharing similar to BitTorrent. While the protocol is an open standard it’s not widely adapted for use outside of Adobe’s technology so it wouldn’t be an ideal solution for other implementations of CypherPoker like JavaScript, for example.

Still, the protocol’s features make a nifty addition to the ActionScript version  and I see no reason why RTMFP wouldn’t be just one among a suite of side-by-side protocols that would be used to provide communications for CypherPoker. It’s still too early to say anything definitively but direct socket communications, WebSockets, XMPP, and basic HTTP transactions are just some of the other ideas that seem viable.

Having done the upfront work I can safely say that Tor, I2P, and other SOCKS5 proxy systems are also in the running but there’s plenty of work yet to be done so RTMFP and MonaServer are good initial options.

November 30th, 2015

Posted In: Development / Coding, Internet / Web

Tags: , , , , , , ,


Then you may like watching me code CypherPoker at

Experience hours of thrilling DEBUGGING! Feel the terror of hideous, grotesque LOGS! Fall in love with dashing RACE CONDITIONS!

Or drop by to chat.

November 5th, 2015

Posted In: Development / Coding, Internet / Web

Tags: ,

One Comment

A group of security researchers recently announced that they had found a serious flaw in the Diffie-Hellman key exchange (the initial “handshake” portion of a HTTPS/SSL session). Specifically, they discovered a problem with many implementations around the web in which the same prime number (modulus) is being used.

The math used for Diffie-Hellman is very similar to CypherPoker’s. Here’s the specific section from CypherPoker’s accompanying documentation where this is described:

A random CB-length prime integer, P, is generated using Maurer’s Method by the activity leader. This value is shared with all participants for subsequent operations.

I’ve mentioned a number of times that this portion of the protocol can be sped up, often significantly, by pre-computing the P value and subsequently dependent values. Undoubtedly, this was the same reasoning used by developers when they baked pre-computed primes into their cryptosystems. According to the group’s research paper:

Generating primes with special properties can be computationally burdensome, so many implementations use fixed or standardized Diffie-Hellman parameters.

True dat.

Although this doesn’t seem especially dangerous (P is publicly shared, after all), it’s not too difficult to conclude that, at least in theory, knowing this value well in advance of a communication could allow an attacker to prepare resultant values that could significantly decrease the amount of time required to find the crypto keys being used. Once this is accomplished the security of the cryptosystem is basically non-existent.

So what does this mean for CypherPoker?

Not much. 🙂

For starters, as I’d mentioned in an earlier post, the encryption for any given game needs to remain secure only for the duration of the game. After that there are actually benefits to being able to break the encryption for any players that had dropped out during a game. In contrast, most public/private keys used in HTTPS handshakes are intended to remain unchanged, and unbroken, for at least a few years.

Secondly, unlike public/private key cryptosystems, both keys in CypherPoker are kept private until a game is complete. I would stress again that I’m not a cryptographer but to me it stands to reason that removing one of the known variables from an equation makes the equation more difficult to solve.

Finally, and most importantly, CypherPoker was built to use dynamic values for every game. In other words, the shared prime value is newly generated for each new game. Although optimizations to the game can skip this step (as the Rochambeau protocol now does), these are optional and secondary (as the Rochambeau protocol now does) rather than being primary and hard-coded.

How much more secure this makes CypherPoker, rather than something like Diffie-Hellman, crosses over into the theoretical realm, and I’m as much of a theoretical mathematician as I am a cryptographer/cryptanalyst, but unless I’ve made included some tragic errors in my code it seems reasonable for me to conclude that CypherPoker is pretty darned secure.

October 17th, 2015

Posted In: Internet / Web, Security

Tags: , , , , , , , ,

Leave a Comment

I’ve been mentioning it as a feature since the early days, and now that CypherPoker has gotten a little more attention people are starting to ask how it can be made to communicate over the internet.

So I made a video:

I’ve covered the underlying RTMFP connectivity a while ago along with hints of other proposals I’ve been bouncing around, but I should mention that these are just two of the more obvious ways that instances of the game can communicate. The book is definitely not being closed on this topic and suggestions are always welcome.

October 10th, 2015

Posted In: Development / Coding, Internet / Web

Tags: , , , , , ,

Leave a Comment

Next Page »