Topic: A solution to centralised pool ownership of the blockchain (Read 2046 times)

let me see if I can attempt to re-clarify this, as it seems people don't understand my proposal here.

Simply:
1) Pool picks a block source "round-robin style" from a list. Gives them the details for first TX (ie their payout address)
2) Block source provides the pool with the block transactions, and a merkle root of the transaction list to verify it hasn't been tampered. This merkle root is then signed by the block source's private key. This signature and merkle root is then given alongside the transactions to the pool.
3) The pool sends out the stratum requests, with one extra field - the signed hash from the block source.
4) The mining software upon receiving a new job, checks the signed hash is valid against the list of block sources it was configured with.
4a) If the hash is valid - it mines...
4b) If the hash is invalid, it stops and/or falls over to second pool.
5) Miner then submits work to the pool in the same way as currently.
6) Pool validates share in the same way as currently.
7) Pool calls submitlock for the shares below the Network target, same way as currently.

Actually, the miners select the ownership. The mining software - as currently would have the extra command line arguments (or conf file) specifying the locations of the block sources. If the pool doesn't use these sources, or the sources are their own sources, then 1) it will be listed publically on their site that they aren't really complying (as they will need to tell miners the sources, in the same way as they have to tell miners the stratum address and port) and 2) miners wont connect.

The issue isn't moved - as the pool with the hash, gets to round-robin control of the block to various sources, Completely and Effectively mitigating such a risk. As I stated in OP, this solution doesn't fix the malicious entity with its own mining power problem - but does fix the current existing issues where co-operative large pools can resolve the 51% problem without any risk to themselves, and infact an incentive to use the new solution.

All you've done is move the issue to another, new kind of pool.
Which could BTW be under the same control as the person running the current pool.
It also means the current-pool selects which new-pool to use, so net effect: ZERO.

Explain? If the pool is not in charge of the block's contents - then how does it not fix the issues associated with having 51%?

No, pools don't have to check every transaction at all, just the coinbase.
Sure, someone could make an invalid block this way, but they could also do block withholding for the same effect.

No, the proposal here doesn't really solve 51% issues at all.

Completely the opposite. GetBlockTemplate would require the pool to verify every transaction is valid, and that the block itself is entirely valid, just to be able to credit a share - as I understand it, it is a computational nightmare.

The miners and pool software would not have to be fundamentally altered to such a large degree, but the resultant change of control would solve every problem of 51% ownership.

This is just a roundabout and centralised way to do getblocktemplate...
Seems pretty pointless.

With a new tx in the block, the merkle tree has would need to be recalculated - changing the block header. This means that the hash inside the coinbase extras would not longer be true for the header, making it invalid - so the mining software would switch or halt mining.

I'm not quite sure I follow. 

How would the mining software verify what the pool operator is doing with the block?  The pool operator still is free to add whatever TXs it likes.  If the pool finds a new block and an old one happens to be floating around to get orphaned, this doesn't imply "going rogue" this is normal operation..  so the mining software should allow it. 

But basically you are right that miners need to have more monitoring tools..   

1) This addresses the issue of trust in the pool in charge. It makes it not possible for double spends or such attacks to occur so long as the pool abides by the rules

2) And it does this by making rules that the mining software can follow - Consequently, if a pool "goes rogue" - all the mining software (if it contains the code) would instantly switch from the pool after 1 block. The mining software can check the headers it receives to verify that the block is from a "block template node" and if not, switch to a back-up pool or if one is not set up, literally stop mining.

Miners would hopefully upgrade their software, as such a change, and solving the issue would make the price more stable, without the imminent threat of "51%" etc.

[-2b-] - The miners are the network for at least the generation of blocks/transations, so they are incentivised to move to the updated software to further secure the network, and therefore their own payments as the value of bitcoin would be better without the 51% issue.

Could you point out 1. exactly what issue this addresses, and 2. how it addresses it?  For 2, specifically, could you point out where in your proposal the network (rather than an honor system of 'pools agreeing to' and 'add checks to mining software') ends up regulating this adoption?
consider this part-bump as the topic was moved

I think you are better off posting in the development subforum

Hi,

I first posted this the other day on Reddit /r/bitcoin but didn't seem to get a response. Personally, I can't see an issue with this - so I would like some more opinions, ideally from more learned and knowledgable persons.

Note: This solution is only for legitimate pools (such as Ghash etc), and is not an intended solution against a compeltely private third party who controls all of the hashing power themselves.

Intentions: The solution should allow any pool to take over as much of the hash-rate for a particular block-chain as they can, without the centralised trust issues usually associated with such a status. Further, this solution does not in any way penalise the finances of such pools, so there is (IMO) no financial incentive NOT to use this solution. Potentially, there is more financial incentive to use this solution, as it removes the negative perception of such situations.

Details:

1) To simplify the situation, create a fork of the bitcoin wallet that contains only the getblocktemplate functionality, without submitblock or getwork functionality. Further, create a fork that contains no getwork or getblocktemplate functionality.

2) Create an API that allows for the disemination of the above template, with a hash in the coinbase (using the extra area) that identifies the providing source, as well as the blocktemplate. The hash is a full hash of the coinbase and all transactions. The API send call contains the information required for the vtx[0] (ie coinbase) block only - this would contain the pool's payout address(es) and payment values.

3) Create a peer-2-peer network for the above nodes, that the API can then be tapped into to.

4) Pools agree to use the wallets without getwork/getblocktemplate functionality, and on block-notify, they call the API for the source nodes, with their payment address(es). This block template is then the one that the pool serves to their miners.

5) When a pool finds a block, this block is submitted to their wallet, and becomes part of the blockchain. The "block provider hash" is also part of the coinbase-extra section, and can be used to verify the source of the hash, and whether or not the block was valid.

6) Finally, create an API for showing this validation, and pools can use this.

7) Add in the above checks to the mining software, such that it will not be allowed to connect to any pools who aren't providing a coinbase with the above "block provider hash" in.

-- This is a preliminary version no doubt with its own issues. But I'm interested to see what everyone thinks. --