I agree, proof of existence enables a lot of interesting use cases. I recently created a project to explore one, an immutable audit history for invoice data (accounting records) [1]. The main advantage seems to be the independently verifiable nature of the audit data. I can just hand over the data, and point to the audit trail, and then it’s up the auditor to do their job.
I skimmed through your devlog post; I think you could make the use case a bit more clear. your service substitutes trust and provides versioning. but trust from whom to whom? I doubt an audit by the government will look in to crypto magic, no?
For an employer a simple log on a somewhat secured server might be enough.
I researched electronic cash registers a bit. here there is also the problem that a gamed system can transmit faked data to which ever system is meaned to provide immutablility.
As stated, it's a proof of concept. The trust element was between the user and the software provider. 'How does a user trust that the software provider doesn't make changes to user data without the knowledge of the user'. In this case, making changes to the audit history and/or invoice data.
While this is unlikely, it's possible. And the point of the blockchain in this case is to make it impossible, at least without being noticeable.
While that doesn't sound all that amazing by itself, it does enable some interesting use cases to be built on top. Now that the data has been made trustless, and verifiable by 3rd parties it could be provided to parties such as: Government, Accountants, Lenders, Banks, etc.
Regarding fake data, sure, you can submit fake data. But when an audit occurs, you need to submit your fake data to be audited. What you can't do, is go back and change the numbers.
https://noisey.vice.com/en_us/article/d37mez/these-7-blockch...