Proof of work already proves enough time passed.
Pow requires real world energy and time.
You can't produce a longer work chain with less time.
So more work is always more time (less the random variance)
Folks, here, I aim for a general audience overview of Proof-of-Time integration to Monero PoW.
True decentralized digital cash must not only be the most private but also the most secure, so it can be relied upon.
PoT is at its core a modest upgrade to Monero's existing PoW protocol, fully compatible with the RandomX algorithm.
PoT doesn't replace PoW. It blends in.
It's a way to improve and secure Monero's PoW mining without starting from scratch and without inventing some damn crazy complex second validation layers.
The PoT upgrade is rather lightweight.
PoT features two different, mathematically determined, and network-level agreed-upon times. Don't think of these as time in a way that is generally understood. It's an internal clock mechanism.
We need mining time and chain time. Once you have both, you can time the chain operations with precision and close all known attack vectors.
The mining time already exists. It has always been there since 2009. Although it's hidden, it's a native part of PoW mining.
Miners still do the same RandomX hashes to hit the network difficulty. The only difference on the mining level is that each valid hash (solution) gets turned into a "deadline," for example, a number between 0 and 180.
It is a pseudo-time that represents seconds "elapsed" since the last block. With the right math, the highest quality hash (the existing winning solution) produces the lowest deadline. The target is 90 seconds to enable 2-minute period blocks.
The chain time is more difficult to understand as it involves some nifty math. The OS time across all peers doesn't have to be synchronized. It's only used for deriving a precise chain time.
Each peer calculates a difference between their system time and the genesis time. This gives the first step toward aligning the chain time across all peers.
Peers gossip via the standard P2P protocol and report their results to other peers. Each peer sorts them by the best and gossips back a median of those results.
The median time is proposed and agreed upon by all peers and then used within a formula each peer uses to adjust to the chain time.
I will not dive into the depths of mathematics. Suffice it to say that the accuracy of the adjustment, which results in the precise chain time, is also exact and can be easily proven - the blueprint delivers the proof.
So, now we have both times. The mining time and the chain time. Instead of blasting the blocks as soon as possible and sorting them out in the aftermath, we give the network a breather.
A 30s window, a grace period, during which the miners do not mine. It exists to accommodate for large network propagation delays and empower the network as a whole to decide on the winning solution before it acts by the end of the grace period.
Before or during the grace period, peers propagate lightweight (circa 150 bytes) intents submitted by the miners. These intents include the proposed solution, the usual, the hash, and the deadline.
Once a peer receives a valid solution that corresponds to the minimum set frequency of blocks (this prevents turbo blocks), it triggers the grace period. Each peer does so upon receiving a valid intent, relative to the chain time.
The intent deadline must be delivered at least 30 seconds before the deadline hits, or it's considered invalid and rejected. For example, a 90-second deadline submitted at the 80-second mark, leaving only 10 seconds, will be rejected.
The grace period doesn't have to start on all nodes at the same time, instantaneously. It just has to end at the same time for all. Since the deadline extends the previous blockchain time, each peer knows exactly when it ends and begins adjusted at the moment a peer receives a valid intent.
In other words, the grace period doesn't have to last for 30 seconds for all peers, although given the lightweight bandwidth requirement of the 150-byte-sized intents, it would work on a 90s-era 56k modem bandwidth, and it does closely.
During the grace period, the peers sort out these intents, pick the best, and at the end of it, the miner's peer who won forges the block, and then block propagation begins.
Hence, it's final right away. No chain reorganizations are possible.
There's a strict rule: one peer = intent. Security conditions applied to the protocol prevent selfish mining within the scope of pre-instant finality.
With PoT, withholding intents would serve no purpose. As I mentioned, a 90-second deadline submitted at the 80-second mark, leaving only 10 seconds, will be rejected.
A miner who delays their solution near the end of the grace period will be detected and rejected by other peers, resulting in a fork of a chain of one, losing all peers. Miners can only benefit from submitting honest intents on time.
PoT opens the door for new, mixed mining models. Solo mining and shared mining.
Miners can choose to solo mine and compete for a full block reward every fifth block, and half of the reward for all the others.
A variety of handicap conditions can be applied. A miner who's winning too many blocks within a 10-block rolling era (e.g., 5), their deadlines get bumped up by 50% or more for the era to give others a fair chance.
In one of the three proposed share mining models, winners split 0.3 XMR among 21 people via a weighted lottery.
It weights chances by an average hashrate from recent deadlines (accurate to 5-20% over time), and caps big miners at 200 "tickets" so small setups aren't outmatched. Repeat winners in shares can get "slashed" to one ticket per rolling block era.
This works great for Monero because we could finally eliminate pools. A protocol that forces people to mine at a pool isn't decentralized.
Pools control about 90% of the hashrate, and PoT empowers the chain by eliminating these central points of failure.
Proof of Time transforms Monero into an asynchronously synchronized timechain, and delivers a security fortress that is unparalleled among PoW based peer-to-peer cash systems.
There's, of course, a lot more to it. The implementation blueprint will clarify the details and address any security or privacy concerns. If any, all can and will be answered.
At this point, I am open to discussing this and welcome any questions and comments.
It's high time we give the PoS ideas a big fat finger and take the unique opportunity to demonstrate to the world how it's done.