Bitcoin Forum
June 14, 2024, 04:21:18 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Prevent PoS users from staking into the past and future?  (Read 27 times)
bushstar (OP)
Hero Member
*****
Offline Offline

Activity: 617
Merit: 531


View Profile
October 27, 2021, 07:59:25 AM
 #1

I'm interested to know different solutions to prevent people "cheating" on block time in PoS.

PoS generates a hash using various things including time, it is time that limits the hash power of PoS as if you stake too far into the future or past you generate a block that is rejected by the network.  For example the following shows a simplified version of how Peercoin generates a hash to check against the target difficulty. blockFrom.GetBlockTime() is the block time.

Code:
CDataStream ss;
ss << nStakeModifier << blockFrom.GetBlockTime() << nTxPrevOffset << txPrev->nTime << prevout.n << nTimeTx;
uint256 hashProofOfStake = Hash(ss.begin(), ss.end());

When mining you create a block with the current time and see if using it you generate a valid hash. To increase your chances of finding a valid hash you would also try generating blocks up to the past and future block time limits. This poses an advantage over those who do not if this behaviour is not built into the coin itself.

The result of baking this into your code to level the playing field is that the block time will start jumping around and after generating a block you'll likely see several more blocks at once, a new block will change the stake modifier giving all stakers full range of time to stake in again. After the flood of blocks there will be a period to wait while no one was able to generate a block in the next time window and has to wait a second a time on the future time limit. That flood of blocks is normally empty as only the first block was the one that took time to stake.

Networks appear to behave more sanely when "super staking" is not built into the code but this gives an advantage to those who know how to exploit it.

Solutions to this seem to be limiting the future and past time windows.

Does anyone know of any other savvy solutions to this?

This is not a new problem and I'm sure that there must have been attempts to solve this over time.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!