Because he cant change the coinbase once the proof of work is done. El 17/06/2014 15:58, "Ron Elliott" escribió: > In this scenario how do you ensure the miner solving the block cannot > reapportion the subsidy to himself rather than the pool? > On Jun 17, 2014 2:09 AM, "Raúl Martínez" wrote: > >> First of all I apologice due to the possible mistakes in my writing >> below, I am not a Bitcoin developer but I have some knowledge about it. >> >> ---- >> >> We all know the recent news, Ghash pool controlling 51% of the hashrate. >> While some consider it a threat others think that is not harmful. >> >> The thing is that we have to do something to stop this from happening >> again. >> >> My proposal is to start thinking about miners that join a pool like >> independent miners and not slave miners, this includes creating a new >> mining protocol that does not rely on the pool sending the list of >> transactions to include in a block. Each individual miner has to collect >> transactions by his own and mine that, this can be achieved by running a >> full node or by running a SPV like node that ask other nodes for >> transactions. >> >> Once this protocol is developed and standarised we as a community could >> require all pools to use it (because its better, because is more >> trustless...), not by imposing it but by recommending it. >> >> Pool owners could send some instructions using this protocol to the miner >> about how many transactions to include per block (some pools want small >> blocks), how many 0 fee transactions to include, how much is the minimum >> fee per Kb to include transactions and some info about the Coinbase field >> in the block. >> >> This way is impossible to perform some of the possible 51% attacks: >> >> - A pool owner cant mine a new chain (selfish mining) (pool clients >> have a SPV or full node that has checkpoints and ask other peers about the >> length of the chain) >> - A pool owner can't perform double spends or reverse transactions >> (pool clients know all the transactions relayed to the network, they know >> if they are already included on a block) >> - A pool owner cant decide which transactions not to include (but >> they can configure the minimum fee). >> - A pool owner cant get all the rewards by avoiding other pools from >> mining blocks (Because the pool client knows the last block independently >> that is from his pool or other). >> >> >> The only thing that a 51% pool owner can do is to shut down his pool and >> drop the hashrate by 51% because he does not control the miners. >> >> If the pool owner owns all the hardware in the pool my proposal is not >> valid, if the pool clients dont use this protocol my proposal is not valid. >> >> >> I want to know if this is possible or its been developed or there is >> already a working protocol that works like this, also I want to read other >> people's ways to address this threat, thanks for reading. >> >> >> ------------------------------------------------------------------------------ >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions >> Find What Matters Most in Your Big Data with HPCC Systems >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration >> http://p.sf.net/sfu/hpccsystems >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >>