Topic: Proof-of-Stake Research Group - page 2. (Read 3031 times)

Nxt can't work properly in a non-synchronous network. We assume that nodes have clocks that don't diverge too much. +/-5 sec divergence is a reasonable window, an ordinary personal computer is able to keep itself within that window without any problems if Internet is available.

Yes. A long block interval softens the issue a bit because there is more time for information to propagate.
As you reduce block interval times connectivity gets more weight. Move block intervals to very very small values and effectively your connectivity will determine the winning chain (given a reasonable distribution of forgers/miners).

It is not the definition of a point in time that is the issue, it is that everyone has a different idea of what the current time is in relation to that point.
Tromp points out the issue that wanting to agree on time is just that, an agreement problem requiring a form of consensus in a distributed system.

How that agreement is formed is another story.

Explain what timestamp is, please. For me, timestamp is a number written in a block header. It can't vary. It's several bits that can't be interpreted differently. If one node sees it as "October 22, 2014, 03:26:16 PM" than all other nodes will see it as "October 22, 2014, 03:26:16 PM".

Isn't every blockchain vulnerable to a similar attack?  For instance in bitcoin when you get a block you could delay releasing it until immediately after you see the next winner.  Some people who are closer to you on the network than to the next winner will then be forked.  If you had enough mining power and fast connections to different places in the world, you might be able to fork off a significant amount of hash power this way.

With timers not being perfectly synchronized,
some will see the timestamp as only 14.999 seconds late, and thus acceptable,
while others will see it as 15.001 seconds late, and thus not acceptable.
Isn't that what your 15sec rule decrees?

Nxt uses so-called "Transparent Forging". In plain English it means that the forger of the next block is known, the timestamp of that block is also known in advance. It's not allowed to set another value for the timestamp, blocks with incorrectly set timestamps are considered invalid and rejected.

Answering your question: If a node purposely sets the timestamp 15 seconds ahead then all other nodes will ignore such the block.

What do you except to happen? Maybe, it is the lack of imagination of what could happen, so please enlighten us.

What if a node purposely sets the timestamp 15 seconds ahead so that there will be large disagreement
on whether the new block has a valid timestamp?
This is a critical issue for network-wide consensus.

Thank you. The most interesting topics for me here is interaction of ordinary p2p computing network with blockchain and taking rewards confirmed externally into PoS system

A whole thread can't be used as a reference. Why didn't you point to a whole forum then? Waiting for the exact quote...

The whitepaper was supposed to be released yesterday evening (the current Gridcoin whitepaper being completely outdated). I will post it, once the developer has published it.

Does Gridcoin have a whitepaper with details on that?

Just wanted to to present a sidekick of Proof of Stake: Proof of Research. It is based on Blackcoin's proof of Stake but contains some extra information in the block header. Miners may choose to partake in BOINC hosted scientific projects. Depending on the amount of quantified work they give for the specific BOINC project, they get an extra reward for a Proof of Stake Block next to their forging reward for the amount of BOINC work. This extra information has the potential of making certain aspects of Proof of Stake more secure.
Currently its only implementation is in the currency it was designed for: Gridcoin.

Timestamp is to be included into block so network members have ability to have determined verification result. However, a node can cheat by shifting timestamp a little bit (see 15 seconds rule in the topic).  Due to this rule difference in clocks should be within a range of few seconds. But that's not the important issue for network-wide consensus, I guess.

In part 2, the function
  verifyHit :: Integer -> Block -> Timestamp -> Integer -> Bool
relies on a timestamp.

How do you propose to deal with the fact that different participants
in the network will have different verification outcomes (due to clock variation)
and the resulting large scale disagreement?

It appears you just shifted the problem from next-block-consensus to time-consensus...

Also see
  https://nxtforum.org/general/forging-questions/?PHPSESSID=q72j729c59804eajc23qt07uo3
where NXT people failed to acknowledge the issue.

Proof-of-Stake is going to be popular distributed consensus algorithm these days. Some properties of the algorithm are very promising, but there are some concerns about it around also. Proof-of-Stake Research Group is here to make research about that!

In the first place, let me introduce myself. I'm Nxt core developer for last few months. To better understand Nxt forging algo I started to model it with Haskell(which is awesome for modelling purposes). Based on the model, two articles were published in my blog:

• Inside Proof-of-Stake CryptoCurrency pt. 1 - Basic Structures  http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocurrency-part-1/
• Inside Proof-of-Stake CryptoCurrency pt. 2 - Forging Algorithm http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocurrency-part-1/

Using this model a friend of mine , andruiman (writing math phd now) made academic-like paper about statistical properties of Nxt forging algo: https://www.scribd.com/doc/243341106/nxtforging-1 (scroll down to view online, to download PDF without FB login use Mega hosting  https://mega.co.nz/#!MJoRnByZ!9i6cZ89SvgtafIAVdlyuJEyqmNAPnvysxF6BCIKjePA ).

We plan to go further, and not around Nxt only. The next step is to make executable open-source simulation of forging process, then expand model. In the first place, we think to model blocktree storage for a forger with contributing to all possible chains of a tree (it's claimed to be a way to produce "nothing-at-stake" issue). We're also going to model some properties of proof-of-stake in more formal way with Coq theorem prover.


From this moment, we're going to call ourselves "Proof-of-Stake Research Group". Both of us are writing phds now(Computer Science / Math). In future we can expand number of participants for sure, but there's no need in that for now.

We're open to communicate with researchers / developers interesting in the topic.


P.S. We would like to get community support for sure:
BTC: 17YksFD7eRB4NhPfEtGrGnuvuwpkAeBd7f
NXT: NXT-R58Z-PUMK-JCG4-5TC6M

(PM for other possible options)