But miners dont want to run full nodes, its better to develop some SPV like that connects to some nodes. Also I believe that stratum mining protocol improves some performance things that GBT lacks. If a new protocol that requires blocks created by miners is developed and named in a cool way, miners could ask for protocol support to his favourite pool. El 17/06/2014 20:26, "Karel Bílek" escribió: > On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca > wrote: > > https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most > > of the pooling-centralization problems. > > This. There is no need to create anything new when GBT already exists. > In my opinion. > > > Unfortunately, it is opt-in, > > and GHash.io doesn't support it. > > Yep. As pools in general are not a part of the bitcoin protocol itself > (nobody cares how the work happened), I am not sure how this can be > forced. > > > Also most miners don't care and don't do the work to set it up. To do > > transaction inclusion themselves, they'd need to run a full node, > > which is a bit more work and resources than just pointing hashpower at > > a stratum server. > > Also, yep. If the miners cared about 51% attack, they wouldn't join > ghash in the first place. All the miners willingly accept the risk in > joining the big pool. > > K. B. > > > If you figure out a way to make GBT widely used (>50% hashpower), kudos > to you. > > > > On Tue, Jun 17, 2014 at 4:57 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 > >> > > > > > ------------------------------------------------------------------------------ > > 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 >