
Proof-Of-Work is a Decentralized Clock - gtrubetskoy
https://grisha.org/blog/2018/01/23/explaining-proof-of-work/
======
rocqua
> The Bitcoin Difficulty adjusts dynamically so that a proper hash is found on
> average once every ten minutes.

So here, the bitcoin network needs to defer to the actual time. The difficulty
is adjusted every 2016 blocks. Then, the time it took to create those blocks
is determined by looking at actual time stamps of the blocks. That is, time
stamps that purport to be the time in UTC when the block was created.

I never understood how these time stamps are trusted and reliable. If I recall
correctly, a block with a creation time that is 'too far of' is supposed to be
rejected by well behaving nodes. Yet, getting accurate time-stamps is the
problem bitcoin is trying to solve.

I suppose that for almost anyone, it is feasible to get time accurate down to
60s and that might be enough that the difficulty calculations aren't affect as
much. Especially due to the averaging over 2016 blocks.

edit:

I found this link en.bitcoin.it/wiki/Block_timestamp it states that:

> A timestamp is accepted as valid if it is greater than the median timestamp
> of previous 11 blocks, and less than the network-adjusted time + 2 hours.
> "Network-adjusted time" is the median of the timestamps returned by all
> nodes connected to you.

So the limits are quite loose.

(An interesting footnote from memory)

The difficulty calculation contains a bug where it calculates the average
block time ignoring either the first or last block. Thus, the block time is
slightly wrong. However, changing this would be a hard-fork because 'the
running concensus code is the spec'. That is, if you fix this bug everyone has
to fix it at the same time.

~~~
johnmaguire2013
If you choose a time in the future, other nodes could reject you.

If you choose a time obscenely short (say, 1 second after the last block),
presumably the difficulty is an average of many created blocks, and it would
take a lot of malicious actors to make this valid.

Plus, if Block A is found at 10:00, and I find Block B at 10:10 but say it was
10:01... and then Block C is found at 10:20, the average of these three is ~10
minutes still.

~~~
tromp
There is no requirement that timestamps be nondecreasing. A block at 10:00 can
be followed by one at 9:59.

What is required however it that a timestamp be at least the median of the
last 11 blocks.

------
rocqua
I think some of this is kind of wrong.

Mostly the claim that "The Difficulty is Intergalactic" is just flat wrong.
Consider a miner on mars with 10% of the hash-rate on earth. Lets say the
light delay from earth to mars is 10 minutes (it is 14 on average).

Now, suppose mars has last seen block B_0 and it was mined on earth (as would
happen most often due to 90% of the hash rate being there). We will call E_1
the next block found if only earth were to mine, and M_1 the block for mars.
Now, mars has two really big dis-advantages. First of all, earth gets to see
B_0 ten minutes before mars does. So, earth can start mining a lot earlier.
Second of all, when mars does find a block, but earth finds a block 10 minutes
later, earth is going to orphan the martian block.

So, if mars has fewer than 20 minutes of advantage over earth, there is a very
good chance any block they find won't matter.

Now, I suppose if the hash-rate is more spread-out over multiple planets, and
one planet isn't dominating things might work out. But we might also see
consensus break down. I might sit down and do the rigorous math on that
tommorow, just to see what happens.

(Other minor nitpicks)

> SHA is Memoryless and Progress-Free

Technically false, because memory-less processes have positive probabilty of
yielding no block after 2^256 tries, whereas for sha-256 using brute force,
this probability is totally 0. I don't think this matters at the current hash-
rate though. (our current hashrate covers about (2.5 * 10^-53)% of the entire
output space every 10 minutes.)

> Trying a SHA Makes You a Participant

Only if you would actually submit your hash if you found a match. The same
holds for the prime-factorization example. If I happen to factor a huge number
and tell no-one I haven't contributed.

~~~
gtrubetskoy
>> Mostly the claim that "The Difficulty is Intergalactic" is just flat wrong.

(I wrote the article) - I see your point, but I think the article is still
correct. Now _communicating_ the winning block is a problem, as you pointed
out, so as a miner on Mars you're at a disadvantage, but that statistically
the probability of solving the puzzle remains same regardless of your location
in the universe is still true.

As someone else pointed out - for the intergalactic version we'd need an
interval much longer than 10 minutes.

This is why 10 minutes was chosen by Satoshi probably - it's plenty of time
for everyone to communicate the solved block, yet not too terribly long in
"human time".

~~~
rocqua
Hi, I hope my tone wasn't too grating.

I stand by my point though, for the purpose of totally ordering blocks, the
difficulty is not intergalactic because a solution on mars is much less useful
than a solution on earth. The problem here is time-delay preventing
simultaneity. This is the same problem that block chain time-stamping hopes to
solve. Thus it seems unfair to me to ignore this problem.

I wonder how tight the 10 minute mark is at the moment. I imagine there might
be nodes that are 5 seconds apart on the network. Maybe even more when we have
backhoe outages. How much lower could the 10 minutes be before we start seeing
to many orphans even on earth?

~~~
ema
If there is no double spend between the later arriving block from mars and the
block earth already mined the next block could acknowledge both. Basically
making the blockchain a blocklatice. If I haven't missed anything the only
reason it wasn't done like this from the beginning is that when the orphan
rate is low it' not worth the additional code complexity.

~~~
rocqua
Interesting! A block lattice seems like a nice thing.

It would be problematic with regards to money creation though. As we get more
blocks per 10 minutes, we get more block-rewards (new bitcoin) per minute.

It also seems weird to 'amend' history by saying some other stuff also
happened.

Thinking of this, could you maybe use this to somehow block a payment by
adding a 'past block' that already spends the bitcoins in your payment?

------
danbruc
This analysis is obviously wrong, if the important thing was establishing a
global clock, you could just use GPS receivers. Ordering transactions works
also without proof of work, just including a hash of an existing transaction
or block in a new transaction or block and this proofs the order of those
transactions or blocks relative to each other. No clock required at all. And
also exactly what Bitcoin does but which is totally unrelated to the proof of
work.

I guess this has been said countless times before, but the role of proof of
work is to establish a somewhat strange kind of identity among anonymous
participants. If you had a trusted list of all participants, you could simply
grant everyone one vote per block and decide by majority whether to accept or
reject a block and get rid of the proof of work altogether. Of course using
some cryptography to establish authenticity of votes and such.

But because Bitcoin is anonymous - or pseudonymous if you insist - there is no
such list of participants and you need a mechanism to prevent participants
from casting an arbitrary number of votes by essentially inventing identities.
And this is what proof of work does, it limits your ability to invent
identities and cast as many votes as you would like by making casting a vote
really hard respectively expensive. The capital costs and the energy
consumption of your warehouse full of ASIC miners become a proxy for your
identity via their hashing power.

And that's it, nothing more, nothing less. The rest follows from here, for
example a 51 % attack is just someone using a lot of money to buy more than
half of all the available identities in the Bitcoin system granting him the
majority of the available votes.

~~~
pdpi
> This analysis is obviously wrong, if the important thing was establishing a
> global clock, you could just use GPS receivers

Is it so obviously wrong? From the first paragraph of the introduction to
Satoshi's Bitcoin Paper: "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".

GPS is a trusted system, whereas bitcoin is designed to be completely trust-
less. The reason why timestamping is a difficult problem is that if I publish
two transactions spending the same money, the network must agree on the order
of events (which is to say: must assign different timestamps to the two
transactions) so that one is considered valid, and the other invalid. Doing
this without proof-of-work leaves you vulnerable to Sybil attacks, where I can
pretend to have an overwhelming amount of nodes in the consensus, and vote for
the more favourable (to me) transaction to be considered the canonical one.

~~~
state_less
Couldn't we save a lot of energy and have a distributed stores of identities
(public keys) with ledgers, something like a git repo per identity?

Whenever I want to spend money, I just commit a changelog to my repo, I want
to transfer some credit to identity X, signed with my identity (private key).
I sign the ledger with my private key and commit the entry to the distributed
store. Push out the changes to anyone who will listen. If you want to forget
my identity and transactions, you may, but if I'm credit worthy, my identity
will probably be remembered and followed.

Github could remember a repo for each of us, but users of the network would
want to mirror the repos, index the repos, and keep an eye out for modified
histories.

I imagine there are likely problem(s) with the idea, can someone explain the
problem?

~~~
danbruc
The problem is, where do your coins come from? Who or what is allowed to bring
coins into existence and what prevents them from just creating as many as they
like? The second problem is, how do you resolve conflicting transactions
spending the same coins?

~~~
state_less
There wouldn't be any coins, instead double entry accounting I
(pubkey:ae32...) owe (pubkey:af41...) 10 US dollars. Medium of exchange is
agreed upon by the two parties, USD is one option.

If you're my friend or a business, and you see my balance is deeply negative,
maybe you don't give some service.

If your my friend or a business, and my credit is not too bad, you follow my
repo and give me some service. You commit a change that says, (pubkey:ae32...)
paid (pubkey:af41...) 10 US dollars and reference my repo and commit.

I don't think there could be double spending because the receiver of the money
acknowledges the credit offer on record (the git repo that paid).

If there are identities and entries in my ledger that are questionable, maybe
you don't count them. For example, you might say credit only counts from those
identities that are willing to answer a two-factor sms challenge. Or, if my
git repo is credited by a google account, that's something worthwhile that
could count toward my balance.

~~~
danbruc
So the entire thing starts with everyone having a balance of zero. Then A
signs a transaction that he gives $1000 to B and we broadcast that
transaction, new balances A $-1000, B $+1000. Now B wants to buy something for
$500 from C and signs a matching transaction. What does C do? Is A a bank that
provided a $1000 loan and therefore C will be able to actually get $500 from
A? Or are A and B one and the same poor guy who just created two keys and
invented $1000 out of thin air?

Maybe I am missing something but I have no idea how that could ever work
unless this is essentially just the current banking system were I know that A
is a trustworthy bank and I will be able to redeem your $500 check. Augmented
with the anti-feature that we are now all broadcasting our balances and all
our transactions to everyone.

~~~
state_less
The important part is A signed over to B $1000. B and C may be the same
person. B wanting to do business as C.

If A, B and C are all the same person and there wasn't an identity attached to
any account, outsiders wouldn't value the record much, especially if they were
transactions of significant value.

C could redeem the value with Western Union (or similar agent). They might say
you have to agree to sign the closure of the account to no longer modify the
balance of the account. They'd basically be like a collections agency, buying
debt.

You'd be able to have similar plausible deniability as Bitcoin. Coinbase sees
the transaction flows and the ledger is public. You could do business as a
pseudo identity ( Do business as C, if you're B )

~~~
icebraining
Thing is, why would Western Union want to buy the debt unless they knew who A
is and if they have any hope of collecting from them? This would probably only
work if A was a known entity, and generally trusted to have the money they
signed over. But if they are, why do we need Western Union at all? Just have C
go to A to ask for the money. And if A is an publicly-known entity that
exchanges signed amounts for the underlying currency, they're essentially an
Exchange.

Combining this, you essentially get GNU Taler:
[https://taler.net/](https://taler.net/)

No proof-of-work, just a way for people to get digital money (representing
USD, gold, or anything else) issued by A (Exchanges). And rather than regular
signatories they use blind ones, so that A doesn't even know that B spent its
coins on C.

------
aey
We are building a ledger based on Verifiable Delay Functions. It's like a high
resolution decentralized clock.

[https://github.com/solana-labs/solana](https://github.com/solana-labs/solana)

------
mad44
[https://muratbuffalo.blogspot.com/2018/03/anatomical-
similar...](https://muratbuffalo.blogspot.com/2018/03/anatomical-similarities-
and-differences.html)

Proof of work is the leader election phase of consensus. It is followed by the
accept phase, where the leader broadcasts the decision to be accepted. The
commit comes eventually and as probabilistic.

~~~
gtrubetskoy
> Proof of work is the leader election phase of consensus.

This is a common misconception stemming from looking at PoW through the
Paxos/RAFT prism. In Paxos a leader is elected, then the leader decides the
order of events. But that's not a valid comparison, because in PoW the
supposed "leader" does not get to decide anything at all - the block has to be
put together prior to "winning the election" (because the block is the _input_
to the SHA).

PoW is a radically different approach - there is no leader, but there exist
indisputable points in "blockchain time", and the order of blocks is
determined by the longest chain, which is essentially a matter of chance.

Another related misconception is that PoW is good, but proof-of-stake is
better. In fact, PoW is the evolution of PoS, not the other way around. A PoS
based digital money was described 1998 by Wei Dai [1], but that approach had
flaws that would only be overcome by a system described Nakomoto's Bitcoin
paper.

1\. [http://www.weidai.com/bmoney.txt](http://www.weidai.com/bmoney.txt)
(B-Money, Wei Dai, 1998)

    
    
      "Each server is required to deposit a certain amount of
       money in a special account to be used as potential fines
       or rewards for proof of misconduct."

~~~
mad44
Leaders don't decide. They propose values (such as a block of transactions).
There may be multiple leaders with different proposals and participants get to
a consensus about which proposal gets accepted for a given slot.

You speak authoritatively, saying "this is a common misconception", but
blockchain is a distributed consensus protocol and I don't think you are
familiar with multileader and leaderless flavors of distributed consensus.

------
andrew1000
The article references "orphans" in blockchain, what becomes of those orphans?
My understanding is that nodes compete to solve the hash - then the "winning"
node has its transactions from the preceding 10 minutes added to the
blockchain. What about all the other (thousands?) of nodes that didn't win -
their transactions must not vanish into the ether, but what becomes of them?
They must get added to the blockchain at some point otherwise something like
bitcoin would collapse on itself, but i've never been able to wrap my head
around how that happens.

~~~
oillio
All the nodes have all the transactions (roughly). When you say the winning
node puts "its" transactions in the block, that is really the transactions
that it is currently aware of, and that fit in the block. All the losing nodes
have the same transactions as well.

When orphan blocks are identified and dropped, any unique transactions in
those blocks are added to the pool of transactions that have the opportunity
to be added to the next block

~~~
icebraining
Well, most of the transactions will be the same, but they _can_ have some
transactions the other doesn't, depending on what transactions they received
and then chose from their own mempool. It's just that those transactions who
got inserted into the "losing" block - but not in the "winning" one - will be
kept around to be added in a new block in the future.

------
tchitra
While the analysis contained in this article is rather arbitrary, blustery and
imprecise, there is a mechanism by which blockchains can serve as 'partially
synchronized clocks.' One interesting facet about Bitcoin is that the model
under which you analyze the effect of network delays can give you different
results about how unsynchronized local copies of the blockchain can become. In
the paper, "Analysis of Blockchains in Asynchronous Networks" [0], a certain
(and more realistic) model is used in which adversarial miners are allowed to
delay forwarding of blocks that they receive. The goal of this model is to
describe how networking can account for changes to the probability of selfish
mining [1]. The authors of [0] prove that for Bitcoin, under some assumptions
about the maximum delay an adversary can use and the block production rate, is
consistent because it has both a lower bound on how much chains between
different participants can differ as well as an _upper bound_ about how far
ahead a single participant can grow their chain. Note that all of these
statements have to be interpreted as statements "with high probability"
relative to security parameters.

In [0], the authors argue that Bitcoin, in particular, is a partially-
synchronized global clock, and they take advantage of it in [2] to make a
hybrid blockchain-DB system that provides more traditional eventual
consistency guarantees.

NOTE: I'm not an author of any of these papers, just a casual observer

[0]
[https://eprint.iacr.org/2016/454.pdf](https://eprint.iacr.org/2016/454.pdf)

[1] [https://arxiv.org/abs/1311.0243](https://arxiv.org/abs/1311.0243)

[2]
[https://eprint.iacr.org/2016/917.pdf](https://eprint.iacr.org/2016/917.pdf)

------
xamuel
Can someone who knows the technical details of bitcoin answer the following
questions? Suppose initially A owns 1BTC and B owns 0BTC. Suppose A publishes
a signed transaction that would give 1BTC to B, and simultaneously B publishes
a signed transaction that would give 1BTC to C. If a miner includes both
transactions in a block, is the block valid? Does it depend on the order of
the transactions within the block (A's transfer to B preceding B's transfer to
C)?

~~~
rocqua
Yes, and this actually has a use.

You can use this to increase the fee of a transaction after the fact. So,
suppose A has a fee of 0.001 in the first transaction, and the current fee
needs to be 0.01 . Then, B has this transaction, but no-one will put it into a
block, so B hasn't really received his money yet. A could sign another
transaction with a higher fee that would send the money back to A. This could
happen until the original transaction was actually deep enough in the chain.

But using your situation, B can do the same thing as A. B can create a
transaction sending his own 0.999 BTC to another address of his, and include a
fee here of 0.019 . In this fee, there is 0.01 to fund this transaction, and
another 0.009 to fund the fee A forgot to include. Miners will see this, and
include both transactions, and B is guaranteed he has his money.

~~~
discussedbefore
> _increase the fee of a transaction after the fact_

Someone should have volunteered to help the Pineapple Fund do this instead of
switching to Bitcoin Cash (or maybe this is what "Child-Pays-For-Parent" is,
and it cost too much).
[https://news.ycombinator.com/item?id=15995391](https://news.ycombinator.com/item?id=15995391)

>> _Since this created a series of unconfirmed transactions, we had to do
something drastic: use Child-Pays-For-Parent with a very significant fee._

~~~
rocqua
> maybe this is what "Child-Pays-For-Parent" is

Yep, this is what that means. The downside is that the 'child' transaction
doesn't just pay for the 'parent' transaction, but also for the 'child'
transaction itself. If you make the child transaction a really complex one
that draws from many parents, that transaction becomes larger (in terms of
bytes) and thus becomes more expensive.

------
hudon
> There is a separate consensus in a rare but common case of two consecutive
> ticks being associated with conflicting blocks. The conflict is resolved by
> what block will be associated with the next tick, rendering one of the
> disputed blocks “orphan”. How the chain will continue is a matter of chance

It being a "matter of chance" may be false and thus the thesis that this clock
is "decentralized" should be questioned. There are situations where there will
be conflicting blocks and no block gets orphaned unless a central authority
commands it to be so. This was seen in the 2013 Bitcoin fork, when Pieter and
Luke ordered the miners to move away from the majority chain (0.8) onto the
minority chain (0.7) and this was also seen in 2016 when Vitalik ordered that
a permanent chain divergence (ie. fork) happen. In both cases, the blockchain
split and a central authority was necessary to resolve the conflict. It was
not a matter of chance. The fact that this clock can have permanently
divergent chains and that a central authority is required to say which chain
should be chosen as the right one means that this clock is not decentralized.

~~~
sethgecko
Fascinating, I found this article by Vitalik that explains what happened. In
v0.8 they swapped from BerkleyDB to LevelDB but due to a bug the two chains
started diverting.

[https://bitcoinmagazine.com/articles/bitcoin-network-
shaken-...](https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-
blockchain-fork-1363144448/)

~~~
hudon
Yup, we'll never know if the bug was intentional or not, and that's why the
fix being centrally coordinated is scary. Maybe it was a legitimate mistake,
but maybe one of the developers planned this and executed large double-spends
on the 0.8 branch because he knew 0.7 would be ultimately chosen. The fact
that nothing prevents this type of attack is worrisome.

You can see how the developers behaved like a central authority in the IRC
logs of the bitcoin-dev channel. More info here: [https://freedom-to-
tinker.com/2015/07/28/analyzing-the-2013-...](https://freedom-to-
tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-
making-saved-the-day/)

------
nikisweeting
Looks like this article describes a system that's very similar to
[http://solana.io](http://solana.io)

------
IncRnd
> _The Bitcoin blockchain Proof-of-Work is simply a distributed, decentralized
> clock._

While this is a cute way of looking at the issue it also isn't true. The
bitcoin blockchain gets updated on average every 10 minutes with the data
produced by proof of work.

The author is saying that the cart pulls the horse, because they are both
moving.

------
lowbloodsugar
To be clear, we're talking about Logical Clocks [0], not what humans usually
think of as a clock or its purpose.

    
    
      [0] https://en.wikipedia.org/wiki/Logical_clock

------
panic
Wouldn't a proof-of-time scheme have a bootstrapping problem? You need some
way to unforgeably (and fairly) generate your Bitcoins before anyone will care
to trade them with you.

------
lainga
On the last section, is a better name for it "Proof-of-Time" or "Proof-of-
Tick" (not that we can likely change the popular name, the cat's out of the
bag)?

~~~
gtrubetskoy
I like Proof-of-Tick :)

------
ptest1
But it isn’t a clock because it doesn’t tell us how much time has passed. PoW
allows for the creation of an ordering. I’m not sure these metaphors are
helpful.

~~~
ghayes
I believe the reference is to a vector clock [0]

[0]
[https://en.wikipedia.org/wiki/Vector_clock](https://en.wikipedia.org/wiki/Vector_clock)

~~~
ptest1
That makes a lot more sense, thanks.

------
xmly
Decentralized TimeStamp Server... This is clearly wrote in the bitcoin white
paper. Why is this becoming a news?

~~~
ajkjk
It's just a blog post; not necessarily 'news'.

------
bitxbitxbitcoin
Well put, sir!

------
throwawaysecops
> Nothing Happens Between Blocks

Actually, this is only partially true. With Lightning, things can most
certainly "happen" in between blocks. Granted, some things that "happen" may
never make it to the main chain, but many things will get rolled up and
committed for all to "see".

This is, ironically, how reality works.

