Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization

["Raúl Martínez" <rme@i-rme.es>]

[-- Attachment #1: Type: text/plain, Size: 5667 bytes --]

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" <kb@karelbilek.com> escribió:

> On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
> <christophe.biocca@gmail.com> 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 <rme@i-rme.es> 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
>

[-- Attachment #2: Type: text/html, Size: 7181 bytes --]