Ideas for an energy saving coin

[afkl]

Do you think there's any advantage in trying to rate-limit the hash rate of a coin?
One idea, more a mental picture, would be:

When there is a block time of 2 minutes, divide it into two parts (2 x 1 minute)
The second part is the usual part called "parallel".

The first and new part would be serialism in some simple and hopefully safe manner,
taking the block hash of the last block, serially iterating for "about one minute" (which has it's typical speed limits). So, apart from the fact that everyone would have different processor speeds for this, there would be exactly one valid solution for this part, and it could also be shared, among units in the mining farm or globally. So, there should be the effect that a farm is "off", doing the serial iterations task, for one minute.

Verifying blocks gets slower, but that would be an increase only for valid blocks anyway, not per solution attempt at mining. It would probably not result in additional power usage.

I think, the whole point would be that it's trying to be an energy saving coin.

[afkl]

Hi, thanks for your reply. Unfortunately I'm no researcher and no crypto developer either.

I've just written these ad-hoc thoughts about the idea. The main concern is - as one might have guessed - energy saving versus centralization.

The serial iterations task

A typical home computer's clock speed is 5GHz and the highest possible speed is maybe around 10GHz. The algorithm may be implemented more efficiently in an ASIC, in the case of CryptoNight this - if the algorithm gets updates against Bitmains efforts to compete - may be a 2 times speed increase, which is actually taken from their figure about graphics cards. In respect to the number of execution units there, the speed increase per execution unit may be less. I just need some rough numbers to not think nonsense.

So one could say there may be a speed gap of 4x between the "egalitarian" average user and the "centralized" investor. That means, the task of serial hash iterations could be completed e.g. in 15 seconds instead of 60 seconds. So, sadly, the ratio of serial task versus parallel task (and thus the amount energy tried to save) is important. The more it relies on the serial task and keeps the parallel thing turned off, the more it could be centralized with using a high clock speed.

I try some math. Assuming the coin trys to get a block time of e.g. 2 minutes serial and 1 minute parallel:
If you finish the serial task in 1 minute instead of 2 minutes, there will be 2 minutes instead of 1 minute for the parallel task, or you have simply doubled your effective hash rate.
So, for all serial/parallel ratios:
hash_rate_multiplication = (parallel_work_duration + serial_work_duration - serial_work_duration / serial_mult) / parallel_work_duration

So if I'd came to the conclusion due to other reasons (51%-attack etc) that the hash_rate should not be effortless doubled (max_okay_hash_rate_multiplication = 2) by one miner,
and the assumed advantage of the faster processor for the serial task is a multiplier (serial_mult) of 4, then:

serial/parallel_ratio = (max_okay_hash_rate_multiplication-1) / (1 - 1 / serial_mult)
serial/parallel_ratio = (2-1) / 0.75
serial/parallel_ratio = ~1,3

So 1.3 minutes serial, 1 minute parallel would be a good ratio if the other values are were true.

In case there are not enough ideal (fastest speed) processors: Since there is only one valid result that belongs to a block hash, the result could be shared. But since that relies on trust, every miner better had an ideal processor themselves.

When there is sharing of results, it's not immediately clear to me whether holding back a newly found block for a certain time by a rogue miner would be in his favor. While it could delay transmission of the result to other miners, it may also increase the risk that he doesn't get the block reward.

Conclusion: Is energy saving by hash rate limitation possible? I'd say yes, but it comes at a cost. Either the serial task is designed so that there can be easily built such an optimal processor for every miner, or there is a good sharing technique, or you cannot save much energy without getting more centralization.

[afkl]

Sorry for the bumping, since it fits here, I just wanted to note down another (rather old) idea for energy saving. It's a system made out of two blockchains where one blockchain is a "clock" to the other, having different incentives.

How to build it:

Step 1)
Create one classic blockchain coin project and duplicate everything of it, nodes, blockchain, software. Now there are:

- Coin A
- Coin B

Step 2)

Alter Coin B so that it does not give block rewards itself. Coin A looks up Coin B's blockchain to have all (A+B) rewards only be used via Coin A. Mining for Coin B is still profitable, merely the usage is changed.

Step 3)

Lower the block reward of Coin B so that it is only 1/10 of Coin A's block reward.

Step 4)

Alter Coin A so that it's blocks need its own block hash + Coin B block hash. This means blocks of A have to wait for blocks of B. The constant block time, lower reward and lower power consumption of Coin B keeps it being an external clock for Coin A, and if the coin gets popular, while Coin B does not die, Coin A keeps being the main interest but has still a lower hash rate than it would have without the clock.
What's really duplicated and what's shared in the system is still to elaborate. The main point is to fight the argument "what if the clock dies". If that wouldn't be an argument, a coin could just wait for bitcoin's hashes.
There should be a mathematical relation between the reward ratio between A and B, the blocktime that A waits for B, and the overall functioning. But that is still a bit unclear to me.

The two coins here (A and B) can also be viewed as a block chain type with alternating blocks, which simplifies it a bit instead of using two complete blockchain-systems.

Classic blockchain: AAAAAA...
Energy saver: BABABA...

A problem is that a miner might want to pump energy into Coin B, decreasing its block time and get Coin A rewards faster. If a miner wants to fast foward the clock (a B-Block) in order to get more A-blocks, which would eventually lead to the same overall power consumption, there should be a penalty that lowers the reward in the A-Block:

B-block (the clock): reward_multiplier = 0, "donkeywork" without reward (was 1/10 above, but 0 should also work)
A-block (the rewarder): reward_multiplier = 1 / energy consumpion of B-Block solution

Now, here the two systems are quite different.

The serial-system in the post above would require a minimum of serial work that blocks any meaningful parallized work for a certain amount of time.
The clock-system (this post) would rather try to prevent speeding up that clock by lowering the reward, while measuring and storing the timings to calculate the energy consumption is another problem.

[sunlitit654]

Appreciating your initiative, but have to study more. Thanks for your suggestion, I have to study more about it. After getting clear vision ill look forward it.

[afkl]

Hi, glad you're also interested.

I've thought again about the "clock" and here's some improvement of the time measurement in order to reward waiting.

- A classic blockchain with all blocks having the same type (AAA..., no two parts, no alternating)
- The miner of a later block measures the reward of the earlier block by taking its duration and giving a high reward for a late answer.
- By nature miners neighbouring in the blockchain are unrelated. The trust in this is similar to the trust in the order of transactions in bitcoin.
- The reward increases exponentially in time. While the risk to lose the block gets bigger, the incentive to wait long is higher than to wait short.
  Constants a and b of the reward curve pow(duration * a, b) are up to some math or experimentation.

block_2
.
. takes duration_2 to be found
. contains: transactions that happened in duration_2
. defines: block reward of block_1 = pow(duration_1 * a, b)
.
block_3
.
. takes duration_3 to be found
. contains: transactions that happened in duration_3
. defines: block reward of block_2 = pow(duration_2 * a, b)
.