Proof-of-Stake Research Group

[Come-from-Beyond]

I am intrigued. As a disclaimer I'm not overly familiar with NXT specific PoS consensus.

From this discussion I gather that a new block might be discarded if the timestamp exceeds certain bounds.
Here are my questions:

If a majority of participants considers the block invalid, will it be dropped in favour of a different block?
If a majority of participants considers the block to be valid, will it be included?

Can both parties mentioned be in disagreement if the block should or should not be included?

If the timestamp has no effect on whether the block is included or not there is no point in going further in this discussion as time drift in this context is irrelevant (though in general the problem persists, I only wanted to point out that time cannot and should not be seen as an infallible tool for consensus)

Blocks rejected only if timestamp is far in the future (more than 15 sec ahead). There is no bound for the past and "longest chain wins" rule determines what branch will be accepted.

> If a majority of participants considers the block invalid, will it be dropped in favour of a different block?
Majority is irrelevant. Every nodes decides itself by following longest chain wins rule.

> If a majority of participants considers the block to be valid, will it be included?
Majority is irrelevant. Every nodes decides itself by following longest chain wins rule.

> Can both parties mentioned be in disagreement if the block should or should not be included?
Yes. Eventually the network will converge because of longest chain wins rule.

[raid_n]

Blocks rejected only if timestamp is far in the future (more than 15 sec ahead). There is no bound for the past and "longest chain wins" rule determines what branch will be accepted.

> If a majority of participants considers the block invalid, will it be dropped in favour of a different block?
Majority is irrelevant. Every nodes decides itself by following longest chain wins rule.

> If a majority of participants considers the block to be valid, will it be included?
Majority is irrelevant. Every nodes decides itself by following longest chain wins rule.

> Can both parties mentioned be in disagreement if the block should or should not be included?
Yes. Eventually the network will converge because of longest chain wins rule.

Either we have a strong misunderstanding or you do not understand how blockchain consensus works.

Blockchain consensus is a majority vote. Each participant has a unique view of the system and will "blindly" follow its perception of the majority, which is the longest chain it knows of.
There can and will be concurrent chains for some time but eventually a majority is formed on one such chain (because it contains the majority of eligible voters).

I will give you an example of how a timestamp disagreement could play out (no idea if that could or does apply to this specific implementation):

Individual clients discard blocks with a timestamp >= 15 seconds in the future
Individual clients see a block with a timestamp of t+x | x < 15 as valid.

Node n has the ability to create a block. It is directly connected to a vast majority of other nodes via direct links.
Node n broadcasts its block rather late for some reason, say at t+14 seconds.
Taking transmission times and local clock differences into account some nodes will receive the block at t>= 15 while some will receive it at t<15.
To those receiving it within the permissible bound it is a perfectly valid block and they will happily continue on using it.
To those that receive it late the block is invalid and they ignore it.

You now basically have two groups of nodes that have a different belief of the blockchain with an equal length. (considering another block is created in time)
Luckily blockchain consensus is exactly built to resolve this issue. As new blocks are added one chain (the one with a majority of participants) outgrows the other in length, persuading more and more
nodes to accept it as the longest chain.


The above example is an abstract description and the problem can be replicated for any element where nodes can potentially disagree on a block.
It says nothing about the probability of occurrence or how the implementation deals with it.

Simply put, if there is ambiguity in accepting a block or not there is always the potential for a temporary fork.

[Come-from-Beyond]

Either we have a strong misunderstanding or you do not understand how blockchain consensus works.

Blockchain consensus is a majority vote. Each participant has a unique view of the system and will "blindly" follow its perception of the majority, which is the longest chain it knows of.
There can and will be concurrent chains for some time but eventually a majority is formed on one such chain (because it contains the majority of eligible voters).

I will give you an example of how a timestamp disagreement could play out (no idea if that could or does apply to this specific implementation):

Individual clients discard blocks with a timestamp >= 15 seconds in the future
Individual clients see a block with a timestamp of t+x | x < 15 as valid.

Node n has the ability to create a block. It is directly connected to a vast majority of other nodes via direct links.
Node n broadcasts its block rather late for some reason, say at t+14 seconds.
Taking transmission times and local clock differences into account some nodes will receive the block at t>= 15 while some will receive it at t<15.
To those receiving it within the permissible bound it is a perfectly valid block and they will happily continue on using it.
To those that receive it late the block is invalid and they ignore it.

You now basically have two groups of nodes that have a different belief of the blockchain with an equal length. (considering another block is created in time)
Luckily blockchain consensus is exactly built to resolve this issue. As new blocks are added one chain (the one with a majority of participants) outgrows the other in length, persuading more and more
nodes to accept it as the longest chain.


The above example is an abstract description and the problem can be replicated for any element where nodes can potentially disagree on a block.
It says nothing about the probability of occurrence or how the implementation deals with it.

Simply put, if there is ambiguity in accepting a block or not there is always the potential for a temporary fork.

How is it different from Bitcoin? As I said, replace time drift with network latency (5 sec difference means 5 sec latency for block propagation). There are not many differences between Bitcoin and Nxt. Almost none if you think of every coin as of a small mining rig.

This is an incorrect statement: "To those that receive it late the block is invalid and they ignore it."
It should be: "To those that receive it late the block is invalid and they ignore it for several seconds."

[raid_n]

How is it different from Bitcoin? As I said, replace time drift with network latency (5 sec difference means 5 sec latency for block propagation). There are not many differences between Bitcoin and Nxt. Almost none if you think of every coin as of a small mining rig.

This is an incorrect statement: "To those that receive it late the block is invalid and they ignore it."
It should be: "To those that receive it late the block is invalid and they ignore it for several seconds."

It is no different to Bitcoin or any blockchain consensus for that matter. I'm not trying to attack NXT here but simply want to point out that your statement about agreeing on a timestamp is misleading.

I don't see how your correction to my statement is correct. If I send out a block very late and only a single other node accepts it it will most likely never make it into the longest chain.
Hence the majority has voted that my broadcast block was invalid. With ambiguity there is no "right" or "wrong" while being undecided.

If a majority receives the block late there is a strong probability it will not be included in the longest chain, ultimately deciding it was invalid.
If only few nodes discard the late block but the majority is building a chain on top of it it will be included, hence those nodes were overruled and they will also accept the block.

This is not a factor of time but one of blockchain length if something will be in the chain or not.

[Come-from-Beyond]

It is no different to Bitcoin or any blockchain consensus for that matter. I'm not trying to attack NXT here but simply want to point out that your statement about agreeing on a timestamp is misleading.

I don't see how your correction to my statement is correct. If I send out a block very late and only a single other node accepts it it will most likely never make it into the longest chain.
Hence the majority has voted that my broadcast block was invalid. With ambiguity there is no "right" or "wrong" while being undecided.

If a majority receives the block late there is a strong probability it will not be included in the longest chain, ultimately deciding it was invalid.
If only few nodes discard the late block but the majority is building a chain on top of it it will be included, hence those nodes were overruled and they will also accept the block.

This is not a factor of time but one of blockchain length if something will be in the chain or not.

Timestamp is used to counteract attempts to forge blocks earlier than allowed. If you send a block very late then indeed it will likely not be accepted. The same in Bitcoin, if you send a freshly mined block late then it will become an orphan. Majority will indeed overrule but only because of longest chain wins rule, not because majority == a lot of nodes. A single node can overrule too if it has the longest chain.

[raid_n]

Majority will indeed overrule but only because of longest chain wins rule, not because majority == a lot of nodes. A single node can overrule too if it has the longest chain.

You can model the distributed system as individual nodes each with the same amount of voting power but where an entity controls multiple nodes (i.e has x hash power or y coins at stake).
Alternatively one should weigh nodes based on their share of the voting power. It really makes no difference though.

The longest chain is created by each consecutive block "agreeing" on the sequence as the longest chain. If you reduce the entire system down to two entities, a and b you see why the majority eventually wins.
While individual blocks alternate between a and b if a has a larger share of resources used to determine the next block they will get drawn more often.
A can decide to allow b's blocks to stay in the chain but can also ignore them completely and make a longer chain. At no point in time can b be absolutely sure that a does not change their mind and start a new chain without him. Eventually that alternate chain will overtake the original one if the distribution of resources stays the same.

The majority always eventually decides on a chain it deems valid. It is important to stress the eventual because the apparent decision on the longest chain is only stable with a certain probability unless it is actually hard coded into the client.

I think it is important to make the distinction because at any one time no "real" decision is made when using blockchain consensus. You are just increasing the probability that that particular reality you perceive won't change again.

[tromp]

This is an incorrect statement: "To those that receive it late the block is invalid and they ignore it."
It should be: "To those that receive it late the block is invalid and they ignore it for several seconds."

You mean that blocks with late timestamps are delayed rather than rejected?

If the timestamp of an incoming block is 5 minutes ahead of my time, do I reconsider it in 5 minutes?

[Come-from-Beyond]

You mean that blocks with late timestamps are delayed rather than rejected?

If the timestamp of an incoming block is 5 minutes ahead of my time, do I reconsider it in 5 minutes?

Yes. Eventually you connect to that node and if it still offers that block and that branch is the longest then you'll download it.

[tromp]

You mean that blocks with late timestamps are delayed rather than rejected?

If the timestamp of an incoming block is 5 minutes ahead of my time, do I reconsider it in 5 minutes?

Yes. Eventually you connect to that node and if it still offers that block and that branch is the longest then you'll download it.

So it would seem to benefit a forger to forge on all the chains they see,
even if not the longest, or if the timestamp is more than 15s ahead.

Because any branch they forge on could eventually become the longest.

Example: last block is at timestamp ts=10.
At time 55, blocks A is announced with ts=60,
and people forge on that, which will lead to a next block at time 115.

At time 60, block B is announced with ts=80.
Now even though not longer and ahead of time by 20s,
everyone might as well forge on that, which could lead to a next block at, say, time 110.

Or block B could be announced at time 120 and be on a strictly shorter chain.
Then it should still be forged on and immediately announce its successor with ts=110.

This would seem to lead to a multitude of branches all extended in parallel.

In bitcoin there is a clear dis-incentive to work on multiple branches.

What dis-incentive is there in NXT?

[Come-from-Beyond]

So it would seem to benefit a forger to forge on all the chains they see,
even if not the longest, or if the timestamp is more than 15s ahead.

Because any branch they forge on could eventually become the longest.

Example: last block is at timestamp ts=10.
At time 55, blocks A is announced with ts=60,
and people forge on that, which will lead to a next block at time 115.

At time 60, block B is announced with ts=80.
Now even though not longer and ahead of time by 20s,
everyone might as well forge on that, which could lead to a next block at, say, time 110.

Or block B could be announced at time 120 and be on a strictly shorter chain.
Then it should still be forged on and immediately announce its successor with ts=110.

This would seem to lead to a multitude of branches all extended in parallel.

In bitcoin there is a clear dis-incentive to work on multiple branches.

What dis-incentive is there in NXT?

There is no a dis-incentive to forge multiple branches because there is no a proof that such activity is harmful.

[tromp]

There is no a dis-incentive to forge multiple branches because there is no a proof that such activity is harmful.

So the point of forging is not to reach consensus?

[Come-from-Beyond]

So the point of forging is not to reach consensus?

The point of forging is to reach consensus.

[tromp]

There is no a dis-incentive to forge multiple branches because there is no a proof that such activity is harmful.

Extending multiple branches indefinitely is clearly harmful to reaching consensus.

[Come-from-Beyond]

Extending multiple branches indefinitely is clearly harmful to reaching consensus.

Maybe. But other factors clearly outweigh this because we don't observe such behavior in the wild. One of such factors may be incentive to forge a single branch to secure value of owned coins (which are used for forging).

[ChuckOne]

There is no a dis-incentive to forge multiple branches because there is no a proof that such activity is harmful.

Extending multiple branches indefinitely is clearly harmful to reaching consensus.

Why do you think those branches will ever win the longest branch race?

[kushti]

Sorry guys, we're reading forums, but prefer to reply in more deep manner
andruiman is preparing another paper on Nxt forging. Then we'll investigate common problems around proof-of-stake.

[kushti]

Hi guys!

Finally, we've changed the group's name to Consensus Research and issued research plan & assets to get funding:

Fundraising Letter -> https://nxtforum.org/consensus-research/first-fundraising-letter/
Asset: "consensus" on AE  https://trade.secureae.com/#5841059555983208287  (it's possible to buy them with Bitcoins there as well)