Quote from: BlackHatCoiner on Today at 03:12:48 PM

Getting rid of the middleman is what's all about your proposal.

Yes, and

Quote

this would require a similar implementation of the original Bitcoin nodes, where pool nodes will run on different servers owned by different people but the software is similar

Quote

I have no experience on mining

But you do understand how BTC works judging by your posts' quality, but to make a long story short of how the current PPS pool work; your miner connects to the pool using stratum protocol where a username is required, the user name is usually obtained from the pool portal but it could very well be your bitcoin address, so the pool knows that miner x whose bitcoin address is bc1... is connected to it, the pool would then send work task to the miner and set a pool difficulty based on the miner's hashrate, let's assume the share difficulty is 10k for miner x, now every share that miner x submits with a difficulty of =>10k is going to be recorded in the pool database.

By the end of the day (usually every 24 hours ) regardless of how many blocks the pool finds, the pool would use a theoretical figure of how many blocks it "was" supposed to find in the past 24 hours should their luck be 100%, and then it's a simple math which tells them how much every BTC address is going to receive for the work they did. [more below]

Quote

If there needs to be a supernode for the network to operate, it can be regulated.

There is no need for a supernode as far as mining is concerned, however, mining is location-sensitive, unlike with Bisq latency needs to be pretty low, so pool nodes need to be located across the globe for this to work effectively.

The topology is as follows:

Miner > pool node > bitcoin node
bitcoin node > pool node > miner

Since we have bitcoin nodes all over the globe it would be pretty easy to connect to them to create the block templates, so anyone running a pool node can connect to his own node or nodes near him to get a list of pending transactions/current block and etc.

The miner would need to connect to a pool node nearby if the latency to the nearest pool node is >200s the miner will need to run their own pool node if this is a simple and easy-to-install executable file with 3-4 next -- problem solved.

Now with the "accounting", using BTC scripting language I think we should be able to design a contract that owns the funds, so any BTC transferred to that contract is now owned by the contract and that includes the block rewards, and then we have to configure the contract to distribute the incoming BTC between the different miners based on the number of shares they submitted - 4% which goes to all the address that deposited funds to the smart contract.

The challenging part, however, is counting the valid shares, since we can't have a centralized database to store all the share counts from thousands of miners, we also can't count on a single pool node to tell us how many valid shares were submitted by every individual miner, to solve this, we could use sharechain which is a similar concept to P2pool.

P2pool was a perfect example of how decentralized mining is doable, it was also a great example of how a decentralized project can die when the requirements to run it is beyond the average Joe, having to run your own local node, install Python and the P2pool software was too much work to many small miners, and then it was a PPLNS pool which judging by the fact that the vast majority of miners now want PPS wasn't favoirble.

The difference here will be, no requirement to run a full node, but rather a pool node that would be lighter and easier to install, and the payout will be PPS-based with funds that are not owned by anyone. I can already see a dozen potential issues in this proposal, I don't think anything of this nature will come into extinct for the next 10-20 years, but ya, this could be a good starting point for further discussion on how a decentralized mining pool that works could be implemented.