Quote from: odolvlobo on September 26, 2021, 08:13:12 PM

Quote

3. Then m2 will know b1_r and makes an equal-work-check: b1_r_h == h(b1_r + 1).

Right?

Yes, I think some of these bugs I would only catch when trying to program it or really go through it. Thank you.

Quote from: odolvlobo on September 26, 2021, 08:13:12 PM

Quote

Assumption: In 'normal BTC' blocks next to each other are not likely to be mined by the same party in game theory.

I think that is a bad assumption because it is actually a common occurrence, and also because your scheme would promote selfish mining -- the miner producing a block has an advantage that depends on the value of N.

But how would I know whether it makes it impossible to save energy? I believe I understand that the attacker has twice the speed, that alone is a big problem. And selfish miners go on top of that. But then I have to admit, my scheme falls apart again.

Quote from: odolvlobo on September 26, 2021, 08:13:12 PM

Quote from: badbbware on September 26, 2021, 11:24:26 AM

Quote from: Meitzi on September 26, 2021, 09:38:25 AM

I will admit, technically I dont understand what you propose. (details)
But questions is, what problem are you trying to solve?
energy? You cant save energy when it is proof of work.

But you can try to do something like the other proof schemes and puzzles which try to be bound by memory size and the like. My proposal is quite the same, but is based on password hashing and trying to stop the chain.

Quote from: Meitzi on September 26, 2021, 09:38:25 AM

You are making a change, which will not make ANY difference. Right?

I believe it would make a difference. The physical work is power over time. For the time where the additional input to the block is unknown, the usual proof work cannot be done. So energy is saved.

Perhaps I don't understand something, but I agree with Meitzi. According to the design of Bitcoin's PoW, the average cost of mining a block approaches the average value of the block reward. That is why more a efficient hardware (in terms of J/hash) does not change energy consumption. How does your scheme change this design?

Now I understand it. But I thought when one would try and risk attacks, and try a long pause, then miners would not be able to scale. You (the miner) need a higher peak power than you already get, which should be the maximum you can get, because the hardware isn't the limit, right? And you want the maximum amount of money already without my scheme. So, shouldn't a pause give some "power relief" at all?

But I think I do get it, it can scale at the hardware and power consumption when the price changes. But the limits (and so the scaling) are unclear to me, I personally would just try and see, if I were really interested in creating it, which I am not.

You're right, the scheme has problems.