This time, it's personal.

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: , , , , , , , , , ,

Leave a 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: , , , , , , ,

Leave a Comment

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

A few people have asked me how secure CypherPoker is, and my reply is usually something along the lines of “that’s a tricky answer”.

The problem I have in explaining is two-fold: I’m not a cryptographer, and we’re not exactly comparing apples to apples when it comes to similar cryptosystems.

But I’ll give it the old college try :)

I’ve been coding for over a couple of decades now so I’m not exactly an amateur, but I’m not at any level that I could honestly provide a theoretically-sound answer.

Still, the fact that the SRA cryptosystem is a close cousin of RSA should provide some realistic answers provided by people far more knowledgeable than me.

Cryptographic Security

The current state-of-the-art for RSA security is 2048 bits. The equivalent to this is 256 CBL in my implementation of SRA (just divide the number of bits by 8). This is considered infeasibly difficult to crack using known attacks and so is considered secure. As computing power increases so will the ability to crack smaller keys so their length must be increased.

In SRA the key length, or CBL, is purposefully variable to accommodate a broad variety of processing power and desired performance. There is no bottom or top end so there is nothing to stop players from cranking it up really high, but the higher the security the lower the performance.

Because RSA and SRA are closely related they are both potentially susceptible to quantum attacks via something like Shor’s algorithm. In both cases this attack centers around finding the factors of the shared prime modulus value. The largest number factored so far is 56153, which is far below any current security threshold, but the eventuality looms nevertheless.

However, there are a couple of wrinkles with the quantum approach:

First, it still takes time to find the factors of the prime modulus value, albeit far less than by using classical computing. With RSA the public key doesn’t change very often so we have a large-ish window of time in which to find its private counterpart. With CypherPoker (SRA) the keys need to remain secret only for the duration of the game after which they must be revealed in order to verify the game. Although the re-keying protocol allows the game to continue whenever a player drops out of the game for any reason, it is still useful to have their missing encryption keys at the completion of the game if we want to be extra thorough in our post-game verification. In effect, breaking the encrypted session would have to be done while the game is still active, which is usually not a very long window of time. Once a game is complete, breaking the encryption is potentially beneficial.

Second, with RSA we know one half of the keys (public) used for crypto operations. Although SRA derives and uses its crypto keys in a similar way to RSA, both keys are private until the end of the game. Again, I’m not an expert in the field but it’s my understanding that this effectively removes one of the known values in Shor’s algorithm, and that sounds like a potential roadblock.

Additionally, with CypherPoker’s re-keying/dropout support the ability to generate new crypto keys at somewhat arbitrary intervals provides extra foils against attackers in games where cards are returned back to the deck. With certain games like Texas Hold’em this wouldn’t necessarily apply*, but it’s certainly a plus for future implementations.

Software Security

Besides the security provided by the cryptosystem, the CypherPoker software provides a couple of additional security features.

These include storing sensitive data like crypto keys in secure locations when not actively in use, and the asynchronous Rochambeau protocol which prevents collusion when determining the initial dealer for a game.

There are other security features that can be added in future versions, some of which should be quite easy to implement. For example, we can automatically turn any visible private cards face down when the player is not viewing them. This would reduce the possibility of any malware on the player’s machine being able to send screen captures of the game window to attackers. Obviously this isn’t a perfect solution, but every little bit helps.

Finally, the fact that CypherPoker is entirely open source has two implications:

First of all, anyone can update and release the software with security features that I haven’t even thought of, and these features can be made available immediately. I genuinely don’t believe that established online poker sites promote cheating, but the fact that they use primarily proprietary software means that players are at their mercy to fix any software security problems.

Secondly, CypherPoker needn’t be exclusively for Adobe’s runtimes. Because the communication protocols are fairly generic I’ve pointed out that JavaScript would make a good candidate for an initial port of the software, and I see no reason why other languages and runtimes couldn’t be used as well. If a JavaScript version turned out to be riddled with security problems then players could easily switch to a C++ version, Python verison, Objective-C version, Java version, and so on. All of these versions should be able to talk to each other so players would be free to make informed choices about which implementations are suitable for them.

So … how secure is CypherPoker?

It would be irresponsible for me to claim that it’s perfect but from my analysis, for what it’s worth,  it’s pretty darned secure. I recognize that there’s always a need for improvement, but when CypherPoker is compared to similar software it’s clear that the product is operating on solid foundations.

* A re-keying operation could be initiated at any point but right now it’s used only when a player drops out.

October 8th, 2015

Posted In: Development / Coding, Security

Tags: , , , , , , , ,

Leave a Comment

It was me. I did the CypherPoker.

Don’t worry if you’ve never heard of it. Unless you’re not part of the humble 23-member CypherPoker subreddit or one of the 6 interested members following the Github repository, I can’t imagine how you’d be aware of the project’s existence let alone guess who done it.

I’m going to leave the project’s history and philosophy for my other blog so here I’ll just cover the more technical details.

Since you probably don’t know what it is, CypherPoker is a peer to peer Texas Hold’em poker game based on the work of cryptographers Adi Shamir, Ron Rivest, and Leonard Adleman (“Mental Poker“). All of the gory details can be found on the GitHub wiki and for the squeamish there’s the lighter “Midnight” series.

To nutshell it, CypherPoker eliminates the need for a server (trusted third party) during game play. Through the dark magics of cryptography, players conduct games entirely between themselves. When not playing with known players (friends, for example), the game provides the foundation for anonymous third-party services like multi-signature cryptocurrency escrow, player introduction and reputation rating, and game verification.

I’ve read a bunch and asked some pretty specific technical questions at local Bitcoin meetups while simultaneously poking the client API; I have a pretty good handle on how to proceed there. Regarding the anonymity part, I’m pretty confident about that too. I’m presently finishing up the Rochambeau protocol which has so far demonstrated that the optimizations planned for the game will make things significantly faster, and I’ve collected the building blocks for verification and reputation rating services. Not just whistlin’ Dixie here.

There’s still a lot to do but the game part is just about done, at least in terms of functionality. Seeing a greater benefit, I spent more time creating a customizable skinning system than an actual skin so the game don’t look so great. But it needn’t not look so great and hopefully not for long.

Rather than discussing the other merits of the plan like I did through Subreddit comments I thought it would be better to jump directly into a direct, barrel-bottom-scraping example:

Since it’s easier and more familiar than doing calculations with 0.004237 Bitcoin, let’s say that the average buy-in for a 3-player game is $1. We’re really low-balling here.

The winner of our cheapie game would walk away with the equivalent of $3 minus the fee for any services we may have provided. Let’s say that our fee is a paltry 1% or $0.03. Balls are super low here.

Now let’s say that we have an old, slow, dual-core clunker lying around on which we can run the game introduction, verification, and escrow (GIVE) services. Our old beater can completely verify and dispatch a game roughly every 5 to 10 minutes per core. Maybe it’ll be faster if verification fails or the crypto being used is weaker but since our balls are already drooping so low we’ll assume the worst-case: 10 minutes per game per core.

This means that our computer will be able to verify up to about 12 games per hour, or 288 games per day. At $0.03 per game, that will produce a daily takeaway of $8.64. We can multiply by a chronically short 28-day month to arrive at a pessimistic total of $241 per month, or $2,892 per year.

We can use an electricity cost calculator to calculate the monthly cost for our highly inefficient box running non-stop in a secluded corner of our apartment at roughly $14 with taxes. Over the course of the year that’ll add up to $168.

In addition to electricity we’re paying for an expensive internet connection, and not with the cheapest provider either. We missed the cut-off date for the introductory discount and we’re paying the regular $108 per month after taxes. Yikes! And don’t forget the $75 we’re shelling out for installation and activation. In the end our internet connection will cost us $1,371 for the year.

Putting it all together, that’s: $2,892 – $1,371 – $168 = $1,353 per year or $112 per month.

If we want to withhold 40% of $2,892 for the maw of some licensing body or state or whatnot we can squeak by on $15.60 per month. After that, each additional processor core or machine would earn about $130.60 more per month (after all deductions), until we hit our bandwidth limit.

Even with fluctuations in the price of Bitcoin, this very pessimistic model could produce enough for an occasional beer. Or it could contribute to a bill payment or help put a little extra food on the table. Whatever turns you on.

But as I said, that’s the bottom of the barrel.

As soon as we adjust any of the unjustly inflated figures I used in my illustration, the outlook becomes rosier. With a more realistic $5 buy-in and a faster quad-core machine capable of verifying closer to the 5-minute limit (about 1100, 3-player games per day), we can calculate a profit of just over $2,600 per month even if all the other numbers and deductions stay the same – including the accursed 28-day month.

Of course this assumes that the machine operates at 100% capacity so we have to tamp down our optimism somewhat, but even if my late-night math is a bit off it’s numbers like these that make me believe that someone out there will find utility in running the GIVE services and in time expand them to include robust and open collusion detection. Chances are pretty good that the equipment that you may be reading this post on, and the connection over which it was delivered, are good enough to give it a whirl.

I’m also fairly certain that existing mainstream client-server operators would be able to fish some nice savings out of this idea but I wouldn’t expect that to happen overnight. The amount that they’ve invested in technology and ongoing operations, not to mention the pains of converting to something significantly different, are unlikely to make CypherPoker an attractive prospect in the short term.

On the player end of things I suspect that when not free, the idea of playing a provably fair game of poker with friends for only the cryptocurrency transaction fee, or with potentially anonymous strangers for a slightly larger one, might be attractive. As I’ve demonstrated, the buy-ins can be very small so no one needs to feel uncomfortable with how much Bitcoin they’re investing. In other words, the broad on-ramp slopes gently and is invitingly lit.

There are many additional opportunities that I can foresee around customizing and adapting the software that extend well beyond peer to peer poker but I don’t want to get ahead of myself; there is, after all, enough for me to be excited about right here. 😉

To verify the following message you can retrieve my public PGP key from the first Reddit post I wrote, the main source code license, or by key ID (677BCC9B) from most certificate repositories like,,, or

Version: GnuPG v2



September 19th, 2015

Posted In: Development / Coding, Internet / Web

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


This is a somewhat tongue-in-cheek rebuttal to Curtis Franklin Jr.’s InformationWeek article, “9 Reasons Flash Must Die, and Soon“.

I’ve employed his article almost verbatim, changing only a few key terms and occasionally adding a few words to demonstrate how the current hysteria about Flash security could readily be turned against JavaScript, HTML5, and browsers. The major difference between Curtis’ post and mine, like most current articles critical of Flash, is that I provide links to back up all of my assertions whereas other articles rely primarily on ambiguous and sometimes entirely false rhetoric.

JavaScript is hungry

Let’s run this down: The world is going mobile. There’s no doubt that more and more of our computing lives happen on handheld devices. Those handheld devices are getting smaller. It won’t be long before you can use the edge of a smart phone to take care of unwanted body hair. And with the thinner devices comes a smaller set of batteries.

Because JavaScript is an interpreted language, it’s heavy — so heavy that, in conjunction with the way HTML renders video, it’s an absolute battery killer.

And it’s not just a battery killer on mobile devices. Want to see how quickly the battery on your laptop can run to zero? Load your browser with a bunch of JavaScript-heavy pages in tabs and let them all run. You can hear the giant electronic sucking sound as the battery winds toward zero.

JavaScript is naive

Many development systems have numerous internal checks to make sure that the code developed is safe for distribution to the big wide world. JavaScript isn’t one of those systems. JavaScript has, historically, allowed all kinds of code to run. To make life better, JavaScript has provided access to a variety of juicy system components in its attempt to allow the best and most impressive animation.

Now, the good folks at W3C have improved JavaScript and its security over the years, but there are still several qualities that make JavaScript a security weakness — we’ll get to those shortly. In the meantime, know that JavaScript’s naive trust in developers and code would be charming — if it were running on someone else’s system.

Many browsers are closed

There’s a lot of really good software out there that’s proprietary. There’s also a lot of very good software that comes from one or another open ecosystem. When you’re looking for weakness, though, a closed system can legitimately be considered a point that’s not particularly strong.

It’s not only that many popular JavaScript interpreters, the browsers, are closed: They’re really pretty darned closed. That closed nature means that many of the security researchers who might work on improvements in open systems are locked out — something that seems to be of little concern to criminals and hackers.

Funny, that.

H.264 is YAMF (Yet Another Media Format)

When you want to save a graphics file or animated selection, you’re generally presented with an extensive list of options. The newer* H.264 video format, with its lovely .mp4 (a format used by nothing else) presents you with yet another media file type to keep track of, store, and consider in the panoply of files that go into a modern website.

Is a file format inherently evil? Well, no, but life is complicated enough. When there are animation options available that don’t require you to use YAMF, do yourself a favor and cut through the media clutter.

* – Newer than Flash

JavaScript isn’t HTML5 isn’t ActionScript

HTML5 is erroneously typified as the new foundation of Web page development and that it eliminates virtually all need for Flash. And here’s the thing: HTML5 is not a programming language despite notable similarities to HTML4. Flash uses ActionScript which is a close cousin of JavaScript, the actual native programming language of the modern browser.

Flash isn’t the single most complicated programming environment to learn and use, but unless you live your entire professional life inside the Adobe Creative Cloud it’s different from any of the other languages you use (except JavaScript and other ECMAScript-inspired languages). Who really needs that kind of complication? Go with an established standard, and use the time you save for more productive activities — like watching more cat videos.

Browsers are Whack-A-Mole Central

Browsers have presented such a rich set of targets to hackers that developers have spent the last decade (and more) chasing an ever-evolving series of vulnerabilities and exploits. And the nature of browsers means that this game is going to continue.

To a certain extent, this is a game that every set of developers plays with the hackers determined to keep them busy. In browsers’ cases, though, their nature as integrated development systems, interpreters, and embedded technologies means many more holes in which those darned hacker-moles can hide. Not even W3C’s standards can provide enough recommendations to use on their pointy little heads.

Browsers let you be stupid

Remember that game of Whack-a-Mole we mentioned? One of the ways that browser programmers deal with the exploits is by releasing updates. And users of the browsers can blithely ignore each and every one of them.

There are thousands of users now using versions of browsers that date back years — versions filled to overflowing with known vulnerabilities and problems. If some of those users are on your payroll, then they might well provide a path from their funny coffee-break animated shorts straight into your corporate files.

JavaScript makes browsers more complicated

JavaScript is most often deployed as an integrated interpreter. On one hand, that means that JavaScript elements can be active as soon as they load on a Web page. On the other, allowing that “always on” capability means your browser gets heavier and heavier, with a number of side effects — all of them bad.

Heavy browsers are less stable, more power-hungry, slower, and less secure. That combination is one of the reasons LinkedIn and Facebook announced that they’re dropping HTML5 and JavaScript in favour of native code by default.

Now, if you then want inetractivity, you have to go into the controls and re-enable JavaScript — yet another complication.

Browsers kill productivity

Have you ever found a great Web video and then another, and another? Then you looked up and an hour had passed? So have your employees. And we’re blaming browsers.

Cute Web video is the greatest enemy of productivity since March Madness. Without all those nifty singing cartoons about the latest crop of moronic politicians, we could all probably work three-day weeks and get as much done.

Darn you, brilliant video producers!

See, an article like this is proof positive that you don’t need Flash to take up your time. Great sarcasm can do that job just fine, thank you.

July 20th, 2015

Posted In: Development / Coding

Tags: , , , , , ,


As I was re-reading an earlier post about HTTPS I remembered one other point I wanted to make about encrypted web sessions: they’re not always necessary and may even be helping to crack security rather than enhance it.

First let’s put this into context:

“We can end government censorship in a decade,” [Google’s Eric] Schmidt said Wednesday during a speech in Washington, according to Bloomberg. “The solution to government surveillance is to encrypt everything.”

It’s interesting to point out that Schmidt is talking about censorship, not surveillance or attacks, but let’s leave this point to another day. Let’s also put aside the issues that I raised in the earlier post. Instead let’s look at the necessity to “encrypt everything”.

Sure it makes sense to encrypt packets going over a public network if you’re sending things like login credentials, but encrypting every single web request does absolutely nothing to protect your privacy. In theory, neither a third-party interloper nor the government would be able to read the contents of the exchanges, but information such as the source IP of requests and the target destination – the metadata – are still completely out in the open; they have to be in order for packets to be correctly routed (and easily blocked/censored). This information leakage is addressed by anonymizing networks like Tor but that gets a little too technical, not to mention laggy, for most people’s purposes.

Besides, if you like to browse the local news during your morning poop, do you really need to add the extra latency and overhead of HTTPS? Unless you’ve signed into the site or some related service provider, there is no advantage to encrypting something that every eavesdropper can inspect. They’d still know which site you’re accessing and can easily find out where from. The contents of message are plainly available for them to view from the host site, as they are for everyone. In fact, unnecessarily encrypting such data opens the door to known-plaintext attacks and potentially weakens security. With every new request attackers gain additional plaintext and ciphertext samples to work with while you’ve gained nothing but a few extra moments to yourself while your device negotiates the encryption.

I’m not a cryptographer but I have a good understanding of HTTPS and although I have no examples to demonstrate my final point it seems pretty self-evident. Unfortunately, I haven’t heard or read these “encrypt everything” criticisms anywhere and it’s concerning that this headlong plunge is being accepted with virtually no discussion.

That said, encryption is extremely useful and has many applications — but it’s also a tricky tool to wield. There are many ways that naive implementations and uses can undermine the security that encryption can supply and the “encrypt everything” movement doesn’t help matters with its broad-brush approach. What we really need is a nuanced discussion, not a sledgehammer.

March 25th, 2015

Posted In: Government, Internet / Web, Privacy / Surveillance, Security

Tags: , , , , ,

Leave a Comment

Next Page »