Hi Dev, what is the nominal block time? 3.5-5 min is probably not a coded value. So which is the real number used by the velocity control and adjusting the difficulty?
Thanks.
/** Block spacing preferred */
static const int64_t BLOCK_SPACING = 5 * 60;
/** Block spacing minimum */
static const int64_t BLOCK_SPACING_MIN = 3.5 * 60;
/** Block spacing maximum */
static const int64_t BLOCK_SPACING_MAX = 7.5 * 60;
Velocity BluePaper
(Prototype Whitepaper)
Contents:
1 - Intro
2 - Importance
3 - Looking ahead
1 - Intro:
Velocity is a re-written feature originally known as "pulse" found in Frycoin. Upon stumbling across this unique feature it
became quickly apparent that although significant amounts of code would need to be re-done the feature itself had a very
good premise in both security and chain stability aspects. This made it very desirable. Work began to rewrite the code about
two weeks ago and has been successfull despite a few small setbacks and bugs that do not actually affect chain stability or
coin operation in any way other than intended.
2 - Importance:
The key importance of Velocity is to constrain the chain with the parameters already defined within the code as apposed to
having things like block spacing and other properties act almost as a suggestion to the chain's operation rather than rule
and law so to speak. This is very important in the sense that sudden increase in hashrate or possible attacks are still a
vulnerability despite the best retarget systems out there being implemented to control block spacing along with network fees,
possible invalid ballance issues while sending transactions and other portions of the blockchain that are enforced with a
double check but still suseptable to an attack wether it be temporary or a double spend that is confirmed and causes users of
the network grief and losses which is unnaceptable.
This is done by the Velocity system being a "tripple check", even after a block during generation has seemingly met all
requirements and is then produced it is now no longer immidiately accepted. Instead it is checked again for inconsistancies and
possible other exploits.
Most notably users will see rejected blocks during the mining or minting phase (or both depending on coin properties),
despite the tendency to assume that there is something wrong with the chain as it is rejecting blocks this is in fact a
completely normal and a welcomed operation.
Reasoning is that rapid block times, incorrect fees, insufficient ballance and other issues can be manipulated by a
talented programmer with malicous intent. To guard from these kinds of situations Velocity checks the generated block against the
chain parameters, first it Velocity checks the block for proper spacing, if the block was generated too quickly it thus has
not met one of the main parameters for the chain and is promptly rejected, staving off possilbe attacks and any kind of
sudden increase in hashrate.
Next the system verifies that previously the client that sent a transaction (if it sent one in the previous block) was in
fact a valid transaction by comparing previous ballance vs current ballance along with fees paid vs minimum fee required to
pay. If any of these parameters are not met (mind you these are standard chain parameters and nothing outlandish) then the
block is again rejected despite being generated successfully.
Thus this system secures the chain, making it more stable, predictable, and overall reliable, instilling confidence that
the blocks that are accepted are indeed blocks that are proper.
3 - Looking ahead:
Overall the system can be expanded to eventually include more checks, more verification and a even more stringent
implementation that may adapt to any kind of features that are added or removed. This makes the system very adaptable and less of
a hassle to work with as it can grow with the coin/token and as it becomes more refined and mature so will this new
security feature called Velocity.
