Proof-Of-Work is a Decentralized Clock

I meant this in the straight forward sense and what GPS essentially provides, a means to globally agree on the current time with a reasonable high resolution.

Suppose we have an oracle that implements this protocol: it publishes a new public key every hour, and at any time someone can present it a blob of data which it will sign with the private key corresponding to the current hour's public key. Furthermore, you can query it for the set of all blobs it has signed with a given public key.

You don't state it explicitly but from »[...] the set of all blobs it has signed with a given public key [...]« I assume more than one blob can be signed with any key pair and I would then also assume every user can get an arbitrary number of blobs signed with each key pair, right? Or did you imagine a limit per user or key pair?

It is obvious that one can implement a distributed ledger with the only security assumption (for each user) being "I trust this oracle" and "I can determine the current time".

This is, at least to me, not obvious and I tend somewhat towards thinking is it not possible or at least not easy. If my interpretation from above is correct and there is no limit on the number of blobs that can be signed with each key pair then it seems to be at least non-obvious how one could reimplement Bitcoin on top of the oracle. Everyone could just fork and create arbitrary long chains of blocks because there is no proof of work slowing the participants down which I turn means that the longest chain is not necessarily the one that the majority considers valid.

Only if the oracle had a limited capacity and all participants flooded the oracle with request as fast as possible one could hope that the majority would be able to create the longest chain assuming the oracle processes all requests fairly. Maybe there is a way [substantially different from Bitcoin] to build a distributed ledger on top of this oracle but, as already said, it is at least to me not so obvious that I could quickly figure out how to do so.

Moreover, lets assume there is an input that leads sha-256 to be our target (so the probability of finding a solution isn't 0 at all). Take the shortest input that meets our target, and call it L. Now, brute-force try all inputs up to length L. You know have P(find solution after 2^L tries) = 1. This cannot happen for a memoryless process.

If you pick your inputs randomly, it remains a memoryless process.

You can modify the rules of the protocol to be slightly more complicated to relax the "no more than 1 tx/account/hr" rule optimistically.

You can't know precisely what "human" time it was in hh:mm:ss, nor does it matter (because the blockchain operates in its own clock). But you do know the "blockchain time" (which is the parent height + 1).

Your first example block was mined exactly at blockchain time known as "height 518807" the second at 518806.

Note that the (first) block happened exactly, not a femtosecond before or after, but exactly at "height 518807". Such precision is not possible with our "human time".

Also note that this is not precise in any meaningful sense, neither in the case of Bitcoin nor in the case of my FTP clock, we are just labeling random points in time with names like »the point in time I found block 12345.« or »the point in time I created the subdirectory 42«. I could throw a plate against a wall at label that as »the point in time that plate hit the wall«.

This labeling does not establish any regular interval, it does not help identifying what this point in time was or what else happened at this point in time. It's a trivial tautology, every event happens at exactly the point in time it happens. And every clock is as precise - in your sense - as Bitcoin, the exact point in time this clocked switched from 11:59:59 to 12:00:00 is not different at all from the exact point in time you minded block 12345.

Maybe that clock was actually 5 minutes fast and it was really only 11:55:00 but that is inconsequential for the way you use »price«, every tick of that clock still labels a precise point in time. But an actual good clock is useful because it assigns labels like »2018-04-18 19:49:17« at regular intervals with some precision depending on the nature of the clock. Bitcoin, the FTP clock, and the plate hitting the wall are useless in that sense because the relation between points in time and the assigned label are to a large extend random. You could use Bitcoin as a crude clock with an time resolution of about ten minutes but that is not a good clock.

Finally note that the Bitcoin clock does not even really tick at the point in time you mined a block because that block might get orphaned or simply rejected for whatever reasons. Only in hindsight can you say that it ticked when this or that block was mined, once there are enough blocks on top of it that it becomes reasonably unlikely that another chain might become the longest one.

Wait, finally finally. What is the point in time you mined block 12345 exactly? There are zillions of subatomic particles moving around in you mining hardware, how would you ever be able to pin down precisely when you mined a block? Did you mine it now or do you have to wait until this electron over there also passes through that transistor here and increase the charge on the capacitor to the left another tiny bit? When you really think about it, the point in time you mined block 12345 becomes quite a fuzzy concept at the microscale. And so even before you start thinking about the uncertainty principle or relativity.