Flipping coins securely over the Internet

I have built Live Coin Flips after I’ve spent some time thinking how can two persons, in remote locations, flip a coin and agree on the result. It’s more challenging than what it looks like at first; flipping a coin while on a live video call is probably the easiest way, but it is not always feasible, and also any sleight-of-hand trick is much much easier to do remotely.

See for example these guys on YouTube predicting the coin flip outcome every time:

So I’ve come up with the idea of using a third-party, independent, unpredictable, universally agreed upon, continuous source of randomness. After some candidates I’ve singled out one: the Bitcoin price.

To make everything simpler, I’ve built a web application to calculate the outcome every minute. By deciding on a date in the future (it doesn’t need to be in the far future, just far enough for the Bitcoin price to not be published yet), you also commit on a certain coin flip outcome which will happen on that date.

You can see it in action here: Live Coin Flips

Let’s go back to static websites

In the era of continuously generated AI content, we can hardly describe the web as static. Yet, Amazon’s “static website” tool seems may be good enough for most.

I’ve collected a couple tools to create static websites on AWS S3, and manage the basic tasks (update SSL certificates, upload files and the like). Want to know why? Read on.

First, even by AWS price standards, static websites on S3 are dirt cheap. They scale with the amount of users, so for a small “experimental” website it might be pennies. This should be compared with the cost of a VPS that is in the 5$/month or so at the cheapest. If the traffic stays small, I have estimated that for around 100kB of data a page, the final cost for a million page loads would be around 10$. Egress fees is about the only cost here.

The other big advantage is scale. Serving a million page loads with a 5$/month VPS can be challenging. The few times by blog had thousands of visitors/hour, WordPress would struggle keeping up. For an S3 bucket however, that’s hardly a problem.

Third, why not; most of my blog viewers would perceive this website as “static” anyway (at least those that don’t leave comments… would you believe this was a thing? Leaving a comment in a website?). I have a feeling that anything that doesn’t need synchronous server-side logic can magically become “static”. Also platform maintenance is greatly simplified.

I’m probably not saying anything new here, but I always think about how much “the cloud” can scale up, without spending a minute thinking how much it can scale down. This is one of those occasions where it does. And actually, I wish it would happen more often.

PHP not parsing POST data?

If your PHP (or any other server side code) is receiving a single $_POST field of raw data, looking more or less like this, instead of receiving your form fields nicely:

——WebKitFormBoundaryVmWPyJJIBR3n18Wk
Content-Disposition: form-data; name=”form-file-1″; filename=”my document.doc”
Content-Type: application/octet-stream
——WebKitFormBoundaryVmWPyJJIBR3n18Wk
Content-Disposition: form-data; name=”form-field-1″

form-value-1
——WebKitFormBoundaryVmWPyJJIBR3n18Wk–

(that WebKitFormBoundary is probably the sign that you are using Chrome)

Then, chances are your javascript is overriding the content-type header. Check out the request headers, and if you find anything looking like this:

Content-Type:application/x-www-form-urlencoded;

or really anything else which is not this:

Content-Type:multipart/form-data; boundary=—-WebKitFormBoundaryVmWPyJJIBR3n18Wk

then you need to fix the content-type header. It might be simpler than you think; try setting it to `false` (in jQuery / Prototype / …) or disable anything javascript is setting there. The browser will take care of it better than what JS is doing.

In my case, I was getting this problem because I was using the js FormData object to extract form data and then sending it the same way it used to do with “regular” form data. Turns out the content-type header should be set differently. Maybe I saved you a couple of hours of searching.

Anagrhash, a anagram generator & reverse hash searching tool

Anagrhash is a tool which can generate anagrams, and test them against a hash.

It is a tool I wrote many years ago for educative purposes, to try out some different concurrency models and inter-thread communication methods in C, and get some basics of programming in the GNU/Linux environment.

It serves as an anagram generator, and can shuffle letters, but can also be set to shuffle whole words in a sentence, use tokens from a list (words which you don’t want to appear simultaneously), and specify separators between tokens (like spaces or commas).

It can also test anagrams which satisfies an exact target hash, or a hash specified with a regular expression.

You can get it on my GitHub page.