A simple solution might be to just cap the number of times the server will validate the receipt without intervention from you to some reasonable number -- say 5 or 10 times. That way, if a group posts a receipt in order to attack you, only the first few will succeed; thereafter the crack will fail and it will likely be downvoted/forgotten about on whatever site it was posted. Now, its still possible that a user might legitimately want to install your app on that number of devices over the lifetime of the app, so when the server finds the number of validations have been exceeded, pop up a messagebox with instructions (or better yet, a template) for contacting you to lodge a support ticket to unstick their validation. That gives you a chance to intervene in mass piracy, while not costing you too much developer effort, or the customer too much trouble -- they write you an email, you make sure their story checks out, and you reset the validation counter in your database -- if you see a thousand requests against that receipt, you know its been compromised, and can react accordingly. This incurs some work on you to intervene, but the difference between (large-scale) piracy and legitimate users will be obvious -- if your game should ever be so popular that the volume of this work overwhelms you, you'll probably be wealthy enough to hire the help.

A skilled cracker will be able to side-step all of this, but IMO the above describes about the right level of effort to go to in stemming the tide of casual piracy.

In another approach, even if your game has no multi-player content, if you can provide *some* kind of service (friends, leaderboards, "cloud" saves, simple online inspection of their character) to online account holders, that can still incentivise them into creating an account and another fringe benefit might be that it simplifies this whole validation business by gaining you an account to tie them to.

A simple solution might be to just cap the number of times the server will validate the receipt without intervention from you to some reasonable number -- say 5 or 10 times. That way, if a group posts a receipt in order to attack you, only the first few will succeed; thereafter the crack will fail and it will likely be downvoted/forgotten about on whatever site it was posted. Now, its still possible that a user might legitimately want to install your app on that number of devices over the lifetime of the app, so when the server finds the number of validations have been exceeded, pop up a messagebox with instructions (or better yet, a template) for contacting you to lodge a support ticket to unstick their validation. That gives you a chance to intervene in mass piracy, while not costing you too much developer effort, or the customer too much trouble -- they write you an email, you make sure their story checks out, and you reset the validation counter in your database -- if you see a thousand requests against that receipt, you know its been compromised, and can react accordingly. This incurs some work on you to intervene, but the difference between (large-scale) piracy and legitimate users will be obvious -- if your game should ever be so popular that the volume of this work overwhelms you, you'll probably be wealthy enough to hire the help.

A skilled cracker will be able to side-step all of this, but IMO the above describes about the right level of effort to go to in stemming the tide of casual piracy.

In another approach, even if your game has no multi-player content, if you can provide *some* kind of service (friends, leaderboards, "cloud" saves, simple online inspection of their character) to online account holders, that can still incentivise them into creating an account and another fringe benefit might be that it simplifies this whole validation business by gaining you an account to tie them to.

I would add a time limit to the restorations aswell, a limit of lets say 5 restorations in a 90 day period is plenty for a legitimate user but pirates will hit that limit almost immediatly, if you also check the geographic location of the users after the limit has been reached you can detect quite easiliy if a reciept has been shared publicly (if you are getting restoration requests from several countries using the same reciept at pretty much the same time you can blacklist it permanently)