3. Then m2 will know b1_r and makes an equal-work-check: b1_r_h == h(b1_r + 1).
Right?
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 because your scheme would promote selfish mining -- the miner producing a block has an advantage that depends on the value of N.
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.
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 fact?