Quote from: garlonicon on Today at 03:25:15 PM

Quote

Now the question what is the fraction of non-pooled miners in Bitcoin network?

You can see for example here: https://github.com/taprootactivation/Taproot-Activation. As far as I know, only the biggest pools were contacted for taproot support, there were no solo miners having some significant power. That means even if your proposal would be backward-compatible, you would ask big mining pools for support, not some independent solo miners. Of course you can rely on solo miners, but then I expect you wouldn't get more than few percent of the mining power supporting your version.

So True. Pool domination is a reality. Now we need a way to complicate life for mining pools.
So I got this new idea that I called: Jakarta Proof of Work. Instead of running a Two-Round PoW, we just directly limit the miners that are going to participate in the hash competition for a block.
Read article here:
or here:
==============Begin==============
The other simple idea is to do like Jakarta’s odd-even traffic policy to limit the number of cars entering Jakarta: the policy stipulates that cars whose license plate ends in an odd number are only allowed to circulate on odd-numbered dates and vice versa. So, like in the case of Jakarta, we don't want every miner to participate in the hash computation all the time. So, we propose a Jakarta PoW (JPoW) where only miners with (hash mod N < K) where, for each block, for each miner with its public key $PublicKey$:
Equation (1): hash = Hash(Block Head + Public Key)
If (hash mod N < K), then the miner will go for the traditional Bitcoin PoW. If (hash mod N > K), then the miner will move to the next block without calculating any hash. $N$ and $K$ are parameters to adjust to determine the number of miners participating in the hash competition. To get a similar model like Jakarta odd-even policy, we can just choose $N=2$ and $K=1$. When a miner receives an $nonce$ from another miner, it can easily verify that the sender is authorized to participate in the hash computation. If all is fine, it accepts the $nonce$ and moves to the next block competition. If the miner sending the $nonce$ is not authorized to participate in the hash computation, the miner receiving the $nonce$ will ignore what it received and continue solving for its own $nonce$ and listening to the network like in Bitcoin. In JPoW, if a miner ignores the rules and just go for the hash calculation, such miner will be ignored by the honest nodes in the network.
With equation (1), it will be still possible for miners that cannot participate in a hash computation to rent their machines to miners that are authorized to hash as the public keys information is available to all miners. So, to resolve this issue, we replace $Public Key$ by $sign(Block Head)$:
Equation(2): hash = Hash(Block Head + sign(Block Head))
The $sign(Block Head)$ can be produced by the miner only. And it is not available to all the miners at the time of the block creation. If a miner wants to participate in a pool, it will need to send its $sign(Block Head)$ to its pool. The pool will still be able to help on the hash calculation.
Even though $sign(Block Head)$ will slow down the process as the pool will still need to wait for its arrival before starting looking for the nonce while hashing for $Hash(Block Head + sign(Block Head) + nonce)$. To complicate the problem further for the pool, we slightly modify the PoW and search for a nonce while hashing the following equation (3): PoW hash = Hash(Block Head + sign(Block Head) + sign(nonce))
The replacement of $nonce$ in PoW by $sign(nonce)$ will force the miner to either share its private key with the mining pool or calculate the hash itself. Sharing one's private key is a significant constraint and it is expected to complicate mining pool formation.
===============End====