Sending shares at protocol level

Now all shares are counted by each mining pool separately. There are solo miners and pool miners. If someone want to mine with other people, then the only way is joining some centralized pool and trusting that the pool operator will be honest. Also, there are some limits regarding minimum required proof of work to get anything. Also, there are many countless discussions about how much power some pool have or don't have, even if these pools don't have so much mining equipment and all they have is just connections with many miners, they are just acting as proxies and distributing block rewards.

The more I think about the whole situation, the more convinced I am that there have to be some way of doing all those things in a pure P2P way. All shares have to be based at least on block headers. So, it should be somehow possible to just connect all miners in P2P way (instead of using pools as proxies) and just sending headers with lower and lower block hashes. In this way, the best "half-baked" headers will quickly propagate over the network.

Having headers alone is not sufficient to verify that the miner is really mining something valuable and not just putting random bytes as merkle root. So, having the best header is just the first stage of "decentralized shares". It can be used to calculate which part of the overall work was done by some particular block header. Then, it is possible to get the coinbase transaction and based on coinbase outputs, it is possible to calculate how many shares should be assigned for each individual output from each coinbase transaction. In this way, it is possible to create a list of coinbase outputs and the list of shares assigned to each output.

Counting every single block is very inefficient. Counting every CPU miner, GPU miner, FPGA miner and ASIC miner globally by each node is not scalable. Distributing rewards from such list by using on-chain transactions is also not possible at all, as many outputs will be below the dust limit or even below single satoshi and then it is impossible to send anything valuable. That's why distributing rewards in the second layer network is necessary. That's also why counting everything by each miner is impossible.

Having headers alone is enough to accept or reject shares based on total proof of work done. So, each node can simply decide how much work is needed for single output to be included in payment list. In this way, the most powerful nodes can be paid directly on-chain right now, they can form one, global P2P pool, also some solo miners may be included if they are powerful enough, but in the long term situation it should turn out that there are lots of nodes and each of them should receive only a tiny fraction of the block reward. So, on-chain rewards finally should be used just to confirm second-layer payments. That leads us to a question: how to join second-layer shares into first-layer shares?

Coinbase outputs in centralized mining pools are usually just owned by the pool operator. That's one of the reason why pool operators have so much power, miners just give them coins directly to their single-signature addresses and they can do whatever they want with these coins. Forgetting about blockchain limits for a while, there could be just N-of-N multisig, where N will be just the number of miners involved. In this way, if there are N miners and they collectively mine one block, all that is needed is single N-of-N multisig address that represents all miners. Then, on-chain situation is quite simple: we have small coinbase transaction with one N-of-N multisig output for all miners and the rest is just other on-chain transactions.

Now, let's return to our problematic N-of-N multisig. Listing all of those N public keys on-chain is not scalable at all. Creating N separate signatures for such output is also not scalable. The problem with having one signature can be solved by using Schnorr signatures. Then, one signature is enough to spend that collectively created output. By using pure ECDSA it is possible to just add all N keys, then single public key and single signature is sufficient. But then, the problem is that nobody can collect all private keys from all miners to sign it. So, we should create something like this here: on-chain it should look like a single public key with single signature, just sending some coins on-chain to some addresses chosen by the miners. That's how it should look like on-chain to make verification quick and easy for everyone and to create something impossible to differ from some powerful solo miner just spending its single signature output. But then, we should return to our second-layer construction to allow creating something like that.

At first, where the miner sees no other miners' shares (and is well connected to the network), it should just include its public key in the coinbase transaction. Then, that miner is just trying to solo mine the whole block, because there is no other possibility until other miners' shares will be visible. The first miner just starts from 32 zero bits and create the smallest possible share. Then, sooner or later there will be some second miner. It should see the first miner's share and then this miner have a choice: to accept that share and join its power with the first miner or to try mining alone. Solo miners' shares will be the same as pool miners' shares, because on-chain it will be just single public key and single signature matching that key. So, if that miner decides to join the power, it should just add its public key to the first miner's key. In this way, there is still only one address in the coinbase transaction. But then, there is another problem: this miner don't have the private key to sign it!

When there are two miners, this should work in the same way as 2-of-2 multisig address, but should contain single public key and single signature to scale properly later when published on-chain. Forgetting about single signatures and single addresses for a while to explain it better, when looking at what is definitely possible now, the second miner can just create 2-of-2 multisig output and put the whole block reward on it. Then, this miner should create a transaction spending that output and splitting the reward between two miners. The coinbase transaction have to mature 100 blocks and also have to be in a block meeting on-chain difficulty, so it is safe to create and sign the spending transaction by both parties. Then, those two miners can safely mine collectively this "share" just by mining any valid blocks that contains this coinbase transaction. All miners have to agree upfront to start mining. If any signatures are missing or if any party don't want to split the whole reward properly, then no miner will start mining this "share" and just use any mining power to mine other shares that are known to be properly signed by all parties.

It seems that this method can be used and implemented right away, just by using N-of-N multisigs instead of what we have today. If there is a need to split the reward below the dust limit, then the block that is mined can just contain proper transactions to handle putting coins to or from Lightning Network channels. To have a complete system, all that is needed is "joining shares", so making it looking like single public keys with single signatures. This is just a draft what I have in my mind, but it seems to be possible, so I am trying to see what is possible by trying to write code for it, but still I am trying to look at the whole concept from some high-level perspective and find any weak points in it. Thoughts?