Quote from: Sonellion on July 27, 2018, 02:52:06 PM

Quote from: Zin-Zang on July 26, 2018, 02:16:51 PM

Cost is not the issue, Each Block has a defined target of say 1 minute between blocks.

Your chain is 3 months behind, and still has a target time of 1 minute, your block height will always be ~ the same 3 months behind and as such never a threat to causing a reorg, because a reorg can only happen if your block height # exceeds the main chain.

So how do you make up the 3 months time difference?

FYI:
Any change to the code to modify the time target between blocks could allow faster blocks, would lower the target difficulty making it a weaker chain and also break consensus with the other nodes, therefore making sure it would never be accepted over the main chain.

FYI2:
The phrase (block production has zero cost) , is incorrect.
There actually is a cost , it is time.
Your block has to wait the coded time before block generation can occur, and those coins go dormant for a coded period, another time factor.
The Time between blocks is hard coded which affects the difficulty # in proof of stake coins, thus defining the strength or weakness of a chain.

What exactly would make a block of a POS coin invalid, e.g. timestamp too late, compared to timestamp of previous block?
A POW coin can have a target time of 1 minute but could be stalled for days. Some shitty ones regularly do this.

If a block has to wait the coded time of 1 minute before block generation can occur, then every node must have really exact system time. Not like Bitcoin

Quote

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.

(quoted from wiki)

With some PoS coins it is a requirement that all nodes be within a certain time frame.
It used to be 2 hours , but a flaw was discovered that allowed people to gain a staking advantage by having such a large time window.
So the window was lowered to 1 minute or lower for most coins to stop the unfair staking advantage.
So if your PC time is >1 minute off from the actual time, any block your system created was refused by the Proof of Stake network.

* Even Bitcoin Requires blocks to be within that 2 hour window to be accepted in their network.*
https://bitcoin.stackexchange.com/questions/5076/what-stops-miners-nodes-lying-about-what-time-a-block-was-mined

Quote from: monsterer2 on July 27, 2018, 09:45:59 AM

Quote from: Zin-Zang on July 26, 2018, 02:16:51 PM

Cost is not the issue, Each Block has a defined target of say 1 minute between blocks.

Your chain is 3 months behind, and still has a target time of 1 minute, your block height will always be ~ the same 3 months behind and as such never a threat to causing a reorg, because a reorg can only happen if your block height # exceeds the main chain.

So how do you make up the 3 months time difference?

FYI:
Any change to the code to modify the time target between blocks could allow faster blocks, would lower the target difficulty making it a weaker chain and also break consensus with the other nodes, therefore making sure it would never be accepted over the main chain.

FYI2:
The phrase (block production has zero cost) , is incorrect.
There actually is a cost , it is time.
Your block has to wait the coded time before block generation can occur, and those coins go dormant for a coded period, another time factor.
The Time between blocks is hard coded which affects the difficulty # in proof of stake coins, thus defining the strength or weakness of a chain.

I really hope you're not the developer of that coin in your sig, because you seem to have some fundamental misconceptions about consensus design.

1) I have already said this above, but I'm going to restate it in plain terms: any concept of time elapsed in a trustless system is utterly unverifiable without an objective measure such as PoW, which is an unforgable proxy for elapsed time

2) In PoS block production has zero cost, see 1)

What I am telling you is , you are wrong.

If you modify the wallet client to place false time date in the blocks , all you are doing is making a hard fork that the other nodes will ignore.

I telling you , you have to run the wallet code unmodified to create the blocks so that the real network would even think about accepting them.

So can you give me a virtual machine that lets me run a wallet application tricking it into thinking 24 seconds is 24 hours.
Because unlike you , I plan on doing some real world testing with it , not limited to speculative discussion.

If you can't provide me with such a virtual machine, then you are nothing more than chicken little running around screaming the sky is falling.