<p>It doesn't let me post a comment so I'll post as an answer instead to dioyziz's answer. I don't see how this is secure because private keys are free to make. So the person with the most private keys and running the most nodes has an advantage as they can generate the most hashes for that particular timestamp. Which essentially turns it into proof-of-work race again. Who can generate a private key that combined with this particular timestamp meets the difficulty condition.</p>

CC BY-SA 4.0
2020-08-05T17:01:00.260Z
2020-08-05T17:01:00.260Z
Ivelin 
<p>Each possible staking input is used to hash a result based on it's properties and compared to difficulty,
a succesful block is created and propagated.</p>

<p>These calculations are consistent and verifiable over the network so it's a matter of propagation and verification as to whether it's accepted.</p>

CC BY-SA 3.0
2017-11-30T01:11:46.213Z
2017-11-30T01:11:46.213Z
watermelon
<p>The minting algorithm for staking is different for various coins; for example, it is different in BlackCoin from Cardano.</p>

<p>There are several approaches to staking, but most of them are susceptible to "grinding attacks" and almost none of them are proven secure against <em>every</em> attack (only argued secure intuitively by showing that certain specific attacks do not work).</p>

<p>To give a concrete answer to your question, I will describe a specific case of a proof-of-stake protocol which is proven secure: the <a href="https://eprint.iacr.org/2017/573.pdf" rel="noreferrer">Ouroboros Praos</a> protocol.</p>

<p>In the Praos protocol, you can imagine each satoshi corresponds to a public/private key pair. The Praos protocol for staking works as follows: If you are an honest staker, you look at the current date and time and round it to the nearest second (the time unit you round it to is configurable in general and corresponds to the synchronous "slots" of the protocol). Say, for example, that you get <code>d = "2018-07-01 00:19:24"</code>. You take that date and time as input, and you sign it with your private key corresponding to your satoshi, obtaining a signature <code>s</code>. You then compare that signature against the difficulty target <code>T</code> to see if <code>s &lt;= T</code>, similar to how bitcoin compares block hashes against the difficulty. If it is, then you have been "elected leader" and you are allowed to generate a block. You first generate the block contents <code>x</code> which consist of the transactions in your mempool as well as a pointer to the previous block. You then sign <code>x</code> using your public key, and produce another signature <code>s'</code>. You then broadcast to the network your signature <code>s</code> illustrating that you have been elected; the current date and time <code>d</code> for election confirmation; the confirmed transactions <code>x</code> which also include the reference to the previous block; and your signature over the block contents <code>s'</code>. The tuple <code>(s, d, x, s')</code> is the block.</p>

<p>Now, other validators can check that you are the rightfully elected leader. They check that <code>s</code> is a signature for <code>d</code>, that <code>s'</code> is a signature for <code>x</code>, that <code>x</code> contains valid transactions and points to the tip of a previous blockchain (with an older timestamp and non-conflicting transactions). Finally they must verify that you meet the target: <code>s</code> must be below <code>T</code>.</p>

<p>This is quite a simple protocol, but, perhaps surprisingly, it can be proven secure. This is what makes it elegant. It's also quite similar to how bitcoin generates blocks. If you are intrigued about why this protocol is secure, I encourage you to read the paper.</p>

<p>A few details:</p>

<ul>
<li>It is possible for bad actors to generate multiple block contents for the same datetime that they have been elected leader. This doesn't cause a problem because honest parties will only generate blocks committing to one older block, thereby breaking ties.</li>
<li>It's possible that two honest parties generate a block at the same time. This is not a problem and can also happen in bitcoin. Such ties will be resolved, as long as the protocol parameters are tweaked to not allow blocks to occur very often among slots (the exact parameters are specified in the paper)</li>
<li>I said above that <code>s</code> is a "signature" on the current time <code>d</code>, but a technical point is that it's not a signature but actually what we call a <a href="https://eprint.iacr.org/2017/573.pdf" rel="noreferrer">VRF - Verifiable Random Function</a>. This is like a signature, except it has the assurance that the output behaves like a random output (such as a perfect hash behaving like a "random oracle").</li>
</ul>

CC BY-SA 4.0
2020-06-26T17:18:55.483Z
(in reality, you are trying to generating blocks as far in advance of the current time as other nodes will let you)
Criticize SE actions means ban
CC BY-SA 4.0
2018-07-31T21:29:24.117Z
2018-07-31T21:29:24.117Z
dionyziz
<p>I am trying to understand POS. I get that POS uses currency held analogous to the hash power held in POW system. More the stake we have, more are our chances of mining the block. At various sources I read that, a miner is chosen deterministically.</p>

<p>Can someone please explain, how miner selection takes place. And how everyone agree on the same miner, there has to be some algorithm involved. </p>

<p>Quite a lot is mentioned here: <a href="https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ" rel="nofollow noreferrer">https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ</a>
but, I can't seem to find the answer to my query.</p>

<proof-of-work><consensus><proof-of-stake>
How does a miner get selected in Proof Of Stake?
Piyush Chittara
# How does a miner get selected in Proof Of Stake?

(Asked by: username_0 on 2017-11-15)

I am trying to understand POS. I get that POS uses currency held analogous to the hash power held in POW system. More the stake we have, more are our chances of mining the block. At various sources I read that, a miner is chosen deterministically.

Can someone please explain, how miner selection takes place. And how everyone agree on the same miner, there has to be some algorithm involved.

Quite a lot is mentioned here: <https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ>
but, I can't seem to find the answer to my query.

**Tags:** proof-of-work, consensus, proof-of-stake


---

## 3 answers

### Answer by username_3 on 2018-07-31. Score: 7 | Accepted answer

The minting algorithm for staking is different for various coins; for example, it is different in BlackCoin from Cardano.

There are several approaches to staking, but most of them are susceptible to "grinding attacks" and almost none of them are proven secure against *every* attack (only argued secure intuitively by showing that certain specific attacks do not work).

To give a concrete answer to your question, I will describe a specific case of a proof-of-stake protocol which is proven secure: the [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) protocol.

In the Praos protocol, you can imagine each satoshi corresponds to a public/private key pair. The Praos protocol for staking works as follows: If you are an honest staker, you look at the current date and time and round it to the nearest second (the time unit you round it to is configurable in general and corresponds to the synchronous "slots" of the protocol). Say, for example, that you get `d = "2018-07-01 00:19:24"`. You take that date and time as input, and you sign it with your private key corresponding to your satoshi, obtaining a signature `s`. You then compare that signature against the difficulty target `T` to see if `s <= T`, similar to how bitcoin compares block hashes against the difficulty. If it is, then you have been "elected leader" and you are allowed to generate a block. You first generate the block contents `x` which consist of the transactions in your mempool as well as a pointer to the previous block. You then sign `x` using your public key, and produce another signature `s'`. You then broadcast to the network your signature `s` illustrating that you have been elected; the current date and time `d` for election confirmation; the confirmed transactions `x` which also include the reference to the previous block; and your signature over the block contents `s'`. The tuple `(s, d, x, s')` is the block.

Now, other validators can check that you are the rightfully elected leader. They check that `s` is a signature for `d`, that `s'` is a signature for `x`, that `x` contains valid transactions and points to the tip of a previous blockchain (with an older timestamp and non-conflicting transactions). Finally they must verify that you meet the target: `s` must be below `T`.

This is quite a simple protocol, but, perhaps surprisingly, it can be proven secure. This is what makes it elegant. It's also quite similar to how bitcoin generates blocks. If you are intrigued about why this protocol is secure, I encourage you to read the paper.

A few details:

* It is possible for bad actors to generate multiple block contents for the same datetime that they have been elected leader. This doesn't cause a problem because honest parties will only generate blocks committing to one older block, thereby breaking ties.
* It's possible that two honest parties generate a block at the same time. This is not a problem and can also happen in bitcoin. Such ties will be resolved, as long as the protocol parameters are tweaked to not allow blocks to occur very often among slots (the exact parameters are specified in the paper)
* I said above that `s` is a "signature" on the current time `d`, but a technical point is that it's not a signature but actually what we call a [VRF - Verifiable Random Function](https://eprint.iacr.org/2017/573.pdf). This is like a signature, except it has the assurance that the output behaves like a random output (such as a perfect hash behaving like a "random oracle").

> **Comments:**
> **username_4**: (in reality, you are trying to generating blocks as far in advance of the current time as other nodes will let you)  

---

### Answer by username_1 on 2020-08-05. Score: 1

It doesn't let me post a comment so I'll post as an answer instead to dioyziz's answer. I don't see how this is secure because private keys are free to make. So the person with the most private keys and running the most nodes has an advantage as they can generate the most hashes for that particular timestamp. Which essentially turns it into proof-of-work race again. Who can generate a private key that combined with this particular timestamp meets the difficulty condition.


---

### Answer by username_2 on 2017-11-30. Score: 0

Each possible staking input is used to hash a result based on it's properties and compared to difficulty,
a succesful block is created and propagated.

These calculations are consistent and verifiable over the network so it's a matter of propagation and verification as to whether it's accepted.


---

