interesting take for a new coin. REDLINE . [REV]

[pineapples]

this is an interesting idea.
I AM NOT GOING TO MAKE THIS COIN.
the idea is purely for sharing..




REDLINE
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
a racing currency with variable block times..
the higher the hash the faster the blocks.

IDLING, as we sit on the starting line, until block 100 when the real PoW begins.
the flag drops and we hit
FIRST gear, as hash and difficulty rise we shift through the gears until we hit
FOURTH gear, and push up into the
REDLINE

//
this is racing PoW style. block times our engine speed, and difficulty our total speed.

 with block times changing from 10 minutes to 20 seconds depending on mining difficulty.
as mining increases we get faster and faster until we hit redline,a gear shift and we go up a gear,
the blocks get slower and then increase again with increased difficulty/hashrate.

PoW period will end at block 18,000
when will it end ? 1 week ? 5 days ? 4 days ?

PoS will have it's own racing style. The more coins staked the larger the rewards and the shorter the block time.
rewards varying from 1% coins to 5% coins per block.


//
at first as we idle at the starting line, blocks are relaxed at 10 minutes.
PoW gives low returns and difficulty increases and does little to influence times ..

then as we hit block 100, the race is on.

PROPOSED DIFFICULTY VS BLOCK TIMES
Proof of Work

IDLING ->    block 100      10 minutes

GEARS
FIRST       0 - 2 GHS,    10 minutes - 2 minutes
2ND         2- 30 ghs,    8 minutes - 1 minutes
3RD         30 -60 ghs   8 minutes - 1 minutes
4TH         60 - 120ghs   8 minutes - 30 seconds
REDLINE      120 ghs ->   30 seconds - 20 seconds


Proof of Stake

DISCLAIMER : i know very little about network weighting so am unwilling to offer any figures here other than proposed block times.
as network weight increases, block time decreases.

90 - 45 seconds.











//
.. V1.2 .. NOTES ..

might be good to increase overall mining time by incorporating such as a "hill climb" after "the sprint"

all values as displayed are used for demonstration purposes, these figures have been generated spontaneously and may benefit from further consideration.

further research may be useful to decide on targeted hash rates for gear shifts. also whether a 5th gear may be useful.
ALSO whether set difficulties vs sliding difficulty ratio against block time would be better.
i.e. diff a= blocktime 60sec
diff b = blocktime 40sec
OR
an algorithmic response to changing difficulty

weighting of Coins Staked will be strongly effected by coins held on exchange.


further idea maybe to adapt tx fees against volume of transactions (block size), plausibly setting a global minimum with  additions depending on last 5 avg block size.
this may result in problems for transactions that are delayed or manual that have mismatching fee value.

-
included images here are google search.
anime influence would be good for all artwork style.

[1715226627]

1715226627

[1715226627]

1715226627

[1715226627]

1715226627

[1715226627]

1715226627

[pineapples]

OK

this is the basic idea.

[prospecta]

TO

THE

MOON

[KriszDev]

It is hard to set the block time based on hashrate. But if you can get the speed and the height you can do like:

Code:

int getBlockTime(*int ghs, *int nHeight)
{
	if(nHeight < 100)
		return 600;
	else if(ghs < 2)
		return rand() % 600 + 120;
	else if(ghs < 60 && ghs > 2)
		return rand() % 480 + 60;
	else if(ghs < 120 && ghs > 60)
		return rand() % 480 + 30;
	else
		return rand() % 30 + 20;
}

[pineapples]

my initial thoughts were to just change the block time based on difficulty, and not do any actual checking beyond that
like any other coin changes blocktime based on hashrate, higher hash shortens the block time, then it retargets back to "correct time"

i assume you can get difficulty from the last block?

[pineapples]

haha i was slightly feverish when i wrote my last reply.
but the idea of not retargeting difficulty sounds good (within certain limits), so block time would change naturally with the extra work put in above expected difficulty.

also using height as a primary variable to check against - for the initial period, on the starting line.
but i cant imagine how that would work how easy it would be to modify the retargeting algorithim to cater for such variability.

..
so setting up the conditions like below seems more appropriate

but i dont understand the use of rand in the quote,

Code:

return rand() % 600 + 120

generates a random number between 120 - 719 ?? but i've seen it used in coins where there shouldnt be a random number, nor should it be a random number here..

so i'm confused

i would demonstrate using some bodgy math which does not relate to any figures in OP ( using diff or ghs whatever) but seemingly more comprehensively covering the range.
eg
if diff between 11 and 20
blocktime = 60 / (diff-10)

It is hard to set the block time based on hashrate. But if you can get the speed and the height you can do like:

Code:

int getBlockTime(*int ghs, *int nHeight)
{
	if(nHeight < 100)
		return 600;
	else if(ghs < 2)
		return rand() % 600 + 120;
	else if(ghs < 60 && ghs > 2)
		return rand() % 480 + 60;
	else if(ghs < 120 && ghs > 60)
		return rand() % 480 + 30;
	else
		return rand() % 30 + 20;
}

[wurstgelee]

You know why.

[pineapples]

hahah i thought this idea was intersting/cool.

maybe i should post it on the DOGE reddit
lol

[bee7]

The next difficulty determined by previous target time and actual time spent to find a block (it may be averaged over  some number of blocks, DGS'ed, KGW'ed, this is not important), but you would like to put the next target time in dependence of the previous difficulty:

Code:

new_diff := old_diff / actual_time * target_time

to meet the target time. Then you redefine the target time. Isn't the problem obvious?

[pineapples]

[BMX]

[pineapples]

[WHITEPAPER]