Hacker News new | past | comments | ask | show | jobs | submit login

I've spent a lot of time trying to understand PoW and came to the conclusion that is a distributed clock of sorts, described here https://grisha.org/blog/2018/01/23/explaining-proof-of-work/

Pretty much, yes. It's kind of spelled out in the Nakamoto paper. From the introduction:

" In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions."

Everything else in Bitcoin is just turning that timestamp server into a practical(ish) system.

Yes, that's why non PoW distributed ledger like the XRPL work essentially the same by only sorting Tx by time and then use a federated byzantine agreement to "filter out" Tx that did not propagate trough the network in a specific time and thus cant be put in correct order. These Tx will be added to the next ledger(block) instead which isn't a problem if block times are just seconds.

Well, it relies on a synchronized clock, so it can't provide a clock. PoW adjusts the difficulty based on the time to try to meet some difficulty target.

In fact, if the time of nodes is not synchronized, it can cause significant problems and vulnerabilities. If time is too fast, the difficulty adjustment algorithm will think it mined too few blocks and decrease the difficulty.

Those aren’t really “significant problems and vulnerabilities”: any given node can lie about what time it is, but you’re not trusting a particular node for more than the outcome of a single contiguous block—and block difficulty “velocity” is capped—so you’d need a Sybil attack to actually walk the difficulty down. Otherwise, even at 49% malicious nodes, consensus is just going to bounce between nodes that say the time was really short, and nodes that give “regular” timestamps, keeping the difficulty roughly constant within the network’s margin of error.

Really, the timestamp field in most PoW systems’ “block” structs (Bitcoin’s, Ethereum’s, etc.) is just defined as “a number that is higher than the one in the parent block, and not so high that when interpreted as a POSIX timestamp it would land 30+ seconds in the future relative to the local node’s time.” So you just need >50% of the nodes to have a ±30s clock sync in order to agree on which blocks are valid for consideration; and even if you don’t have that level of synch, those blocks will still become valid eventually, once they’re old enough that all the nodes do consider them to be in the past. (And most PoW systems keep around near-“future” blocks until they’re valid for just such a case.)

The timing aspect is an important part of PoW, but it's not the entire purpose. The Bitcoin whitepaper itself goes on to say, "The proof-of-work also solves the problem of determining representation in majority decision making." That is, PoW also solves the problem of deciding which consensus rules to enforce, not just when.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact